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Motorola 88000 Processor and the System V 
ABI 


The System V Application Binary Interface, or ABI, defines a system interface 
for compiled application programs. Its purpose is to establish a standard binary 
interface for application programs on systems that implement UNIX System V 
Release 4.0 or some other operating system that complies with the System V 
Interface Definition, Issue 3. 

This document is a supplement to the generic System V ABI, and it contains 
information specific to System V implementations built on the M88000 processor 
architecture. Together, these two specifications, the generic System V ABI and 
the System V ABI Motorola 88000 Processor Supplement, constitute a complete 
System V Application Binary Interface specification for systems that implement the 
architecture of the M88000 processor. 
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How to Use the Motorola 88000 Processor ABI 
Supplement 


This document is a supplement to the generic System V ABI and contains infor¬ 
mation referenced in the generic specification that may differ when System V is 
implemented on different processors. Therefore, the generic ABI is the prime 
reference document, and this supplement is provided to fill gaps in that 
specification. 

As with the System V ABI, this specification references other publicly-available 
reference documents, especially the MC88100 User's Manual. All the informa¬ 
tion referenced by this supplement should be considered part of this 
specification, and just as binding as the requirements and data explicitly included 
here. 


Evolution of the ABI Specification 

The System V Application Binary Interface will evolve over time to address 
new technology and market requirements, and will be reissued at intervals of 
approximately three years. Each new edition of the specification is likely to con¬ 
tain extensions and additions that will increase the potential capabilities of appli¬ 
cations that are written to conform to the ABI. 

As with the System V Interface Definition, the ABI will implement Level 1 and 
Level 2 support for its constituent parts. Level 1 support indicates that a portion 
of the specification will continue to be supported indefinitely, while Level 2 sup¬ 
port means that a portion of the specification may be withdrawn or altered after 
the next edition of the ABI is made available. That is, a portion of the 
specification moved to Level 2 support in an edition of the ABI specification will 
remain in effect at least until the following edition of the specification is pub¬ 
lished. 

These Level 1 and Level 2 classifications and qualifications apply to this Supple¬ 
ment, as well as to the generic specification. All components of the ABI and of 
this supplement have Level 1 support unless they are explicitly labeled as Level 
2 . 
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Software Distribution Formats 


Physical Distribution Media 

Approved media for physical distribution of ABI-conforming software are listed 
below. Inclusion of a particular medium on this list does not require an ABI- 
conforming system to accept that medium. For example, a conforming system 
may install all software through its network connection and accept none of the 
listed media. 

■ 5.25-inch floppy disk: 96 TPI (80 tracks/side) doubled-sided, 15 

sectors/track, 512 bytes/sector, total format capacity of 1.2 megabytes per 
disk. 

■ 3.5-inch floppy disk: 135 TPI (80 tracks/side) double-sided, 18 sectors/track, 
512 bytes/sector, total format capacity of 1.44 megabytes per disk. 

■ 1/2-inch reel-to-reel tape: conforms to ANSI-standard reel-to-reel tape stan¬ 
dard which consists of 9 tracks, 1600 BPI, no label. 

■ 150 MB quarter-inch cartridge tape in QIC-150 format. 

The QIC-150 cartridge tape data format is described in Serial Recorded Magnetic 
Tape Cartridge for Information Interchange, Eighteen Track 0.250 in. (6.30 mm) 10,000 
bpi (394 bpmm) Streaming Mode Group Code Recording, Revision 1, May 12,1987. 
This document is available from the Quarter-Inch Committee (QIC) through Free¬ 
man Associates, 311 East Carillo St., Santa Barbara, CA 93101. 
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Machine Interface 


Processor Architecture 

The MC88100 User's Manual defines the processor architecture. Programs 
intended to execute directly on the processor use the instruction set, instruction 
encodings, and instruction semantics of the architecture, with the following 
exceptions: 

■ A program shall use only the instructions defined by the architecture. 

■ A program shall execute neither an xmem nor an Ida instruction with an 
immediate imm 16 field. 

■ A program shall not rely on the occurrence of a trap upon execution of a div 
or divu instruction with a zero divisor. 

To be ABI-conforming, the processor must implement the architecture's instruc¬ 
tions, perform the specified operations, and produce the specified results. The 
ABI neither places performance constraints on systems nor specifies what instruc¬ 
tions must be implemented in hardware. A software emulation of the architec¬ 
ture could conform to the ABI. 

Some processors might support the M88000 architecture as a subset, providing 
additional instructions or capabilities. Programs that use those capabilities expli¬ 
citly do not conform to the M88000 ABI. Executing those programs on machines 
without the additional capabilities gives undefined behavior. 


Data Representation 

Byte Ordering 

ABI compliant programs shall use Big-Endian byte order in all interfaces 
described in this document. ABI compliant programs can assume that the Proces¬ 
sor Status Register (PSR) byte order (BO) bit specifies Big-Endian byte order. 
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C Fundamental Types 

Figure 3-1 shows the correspondence between ANSI C's scalar types and the 
processor's. 


Figure 3-1: C Scalar Types 


Alignment 

Type C sizeof (bytes) MC88100 


Integral 

signed char 
char 

1 

1 

signed byte 

unsigned char 

1 

1 

unsigned byte 

short 

signed short 

2 

2 

signed halfword 

unsigned short 

2 

2 

unsigned halfword 

int 

signed int 
long 

signed long 

enum 

4 

4 

signed word 

unsigned int 
unsigned long 

4 

4 

unsigned word 

Pointer 

any-type * 
any-type (*) () 

4 

4 

unsigned word 

Floating-point 

float 

4 

4 

single-precision 

double 

8 

8 

double-precision 

long double 

8 

8 

double-precision 


A null pointer (for all types) has the value zero. 
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V The long double type has the same size and alignment as the double 
type for this version of the ABI. This relationship is Level 2: future ver¬ 
sions of the Motorola 88000 Processor ABI Supplement may provide a dif¬ 
ferent long double type. 

Aggregates and Unions 

An array assumes the alignment of its elements' type. The size of any object, 
including arrays, structures, and unions, always is a multiple of the object's 
alignment. Structure and union objects may, therefore, require padding to meet 
size and alignment constraints. 

■ The alignment of a structure or a union is the maximum of the alignment of 
its elements. 

■ Each member is assigned to the lowest available offset with the appropriate 
alignment. This may require internal padding, depending on the previous 
member. 

■ A structure's size is increased, if necessary, to make it a multiple of the 
structure's alignment. This may require tail padding , depending on the last 
member. 

In the following examples, members' byte offsets appear in the upper left 
corners. 


Figure 3-2: Structure Smaller Than a Word 


struct { Byte aligned, sizeof is 1 

char c; 

}; 
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Figure 3-3: No Padding 


struct { 


char 

c; 

char 

d; 

short 

s; 

long 

n; 

}; 



Word aligned, sizeof is 8 


0 

c 

i 

d 

2 

S 

4 

n 


Figure 3-4: Internal Padding 


struct { 

char c; 
short s; 

}; 


Halfword aligned, sizeof is 4 


0 

c 

pad 

2 

s 
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Figure 3-5: Internal and Tail Padding 


struct { 

char c; 
double d; 
short s; 

}; 


Double aligned, sizeof is 24 


0 

c 

1 

pad 

4 

pad 

8 

d 

12 

d 

16 

S 

pad 

20 

pad 


Figure 3-6: union Allocation 


union { 

char c; 
short s; 
int j; 


Word aligned, sizeof is 4 


0 

c 

pad 

0 

s 

pad 

0 

j 


Bit-Fields 

C struct and union definitions may have bit-fields , defining integral objects with 
a specified number of bits. 
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Figure 3-7: Bit-Field Ranges 


Bit-field Type 

Width w 

Range 

signed char 


-2 W ~ 1 to 

char 

1 to 8 

0 to 2^-1 

unsigned char 


0 to 2“'-l 

signed short 


_ 2 w-l to 2W-1-1 

short 

1 to 16 

0 to 2 w -l 

unsigned short 


0 to 2®-l 

signed int 


_ 2 w-i to 

int 

1 to 32 

0 to 2 W -1 

enum 

0 to 2 W -1 

unsigned int 


0 to 2 W -1 

signed long 


-2 w ~ l to 2 w ~ l -l 

long 

1 to 32 

0 to 2 W -1 

unsigned long 


0 to 2 W -1 


"Plain" bit-fields always have non-negative values. Although they may have 
type char, short, int, or long (which can have negative values), these bit-fields 
are extracted into a word with zero fill. Bit-fields obey the same size and align¬ 
ment rules as other structure and union members, with the following additions. 

■ Bit-fields are allocated from left to right (most to least significant). 

■ A bit-field must entirely reside in a storage unit appropriate for its declared 
type. Thus a bit-field never crosses its unit boundary. 

■ Bit-fields may share a storage unit with other struct/union members, 
including members that are not bit-fields. Of course, struct members 
occupy different parts of the storage unit. 

■ Unnamed bit-fields' types do not affect the alignment of a structure or union, 
although individual bit-fields member offsets obey the alignment constraints. 

The following examples show struct and union members' byte offsets in the 
upper left corners; bit numbers appear in the lower corners. 
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Figure 3-8: Bit Numbering 


0x01020304 


0 

1 

2 

3 



01 

02 

03 


04 


31 

23 

15 

7 


0 


Figure 3-9: Left-to-Right Allocation 

struct { 

int j: 5; 

int k:6; 

int m: 7 ; 

}; 


Word aligned, sizeof is 4 


0 

j 

k 

m 

31 

26 

20 


pad 


Figure 3-10: Boundary Alignment 


struct { 


short 

s: 9 

int 

j : 9 

char 

c; 

short 

t: 9 

short 

u: 9 

char 

d; 


Word aligned, sizeof is 12 


0 

s 

31 

j 

22 

pad 

13 

C 

0 

4 

t 

31 

pad 

22 

U 

15 

pad 

6 0 

8 

d 

31 

9 , 

pad 

23 
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Figure 3-11: Storage Unit Sharing 


struct { 

char c; 
short s:8; 

}; 


Halfword aligned, sizeof is 2 


0 

1 

c 

s 

15 

7 0 


Figure 3-12: union Allocation 

union { 

char c; 
short s:8 ; 

}; 


Halfword aligned, sizeof is 2 


0 

c 

15 

pad 

7 

0 

s 

15 

pad 

7 0 


Figure 3-13: Unnamed Bit-Fields 


struct { 


char 

c; 

int 

: 0; 

char 

d; 

short 

: 9; 

char 

e; 

char 

: 0; 


Byte aligned, sizeof is 9 


0 

c 

31 

1 

: 0 

23 

4 

d 

31 

pad 

23 

6 

: 9 

15 

pad 

6 0 

8 

e 

31 
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FORTRAN Data Types 

Figure 3-14 shows the correspondence between FORTRAN'S scalar types and the 
processor's. 


Figure 3-14: FORTRAN Scalar Types 


Alignment 


Type 

FORTRAN 

Size 

(bytes) 

MC88100 

Character 

CHARACTER* (n) 

n 

i 

byte sequence 

Integral 

LOGICAL 

4 

4 

word 

INTEGER 

4 

4 

signed word 


REAL 

4 

4 

single-precision 

Floating-point 

DOUBLE PRECISION 

8 

8 

double-precision 

COMPLEX 

8 

4 

paired single¬ 
precision 


The logical data type has value . false . if, and only if, it is binary zero. Other¬ 
wise, the value is . true .. 

Some FORTRAN programs that conform to ANSI Standard X3.9-1978 are not sup¬ 
ported within this standard. Programs that force the compiler to produce 
misaligned storage allocation of double-precision real (typically using the common 
and/or equivalence statements) are not supported. 


NOTE 


Support of these programs would degrade the performance of double¬ 
precision arithmetic in all programs. It is suggested that conforming com¬ 
pilers inform the user of such a misalignment. 
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Figure 3-15 shows additional, optional FORTRAN scalar types and their imple¬ 
mentation on the MC88100. 


Figure 3-15: Optional FORTRAN Scalar Types 


Alignment 

Type FORTRAN Size (bytes) MC88100 


Integral 

LOGICAL*1 

l 

1 

byte 

LOGICAL*2 

2 

2 

halfword 

LOGICAL*4 

4 

4 

word 

INTEGER*1 

1 

1 

signed byte 

INTEGER*2 

2 

2 

signed halfword 

INTEGER*4 

4 

4 

signed word 

Floating-point 

REAL*4 

4 

4 

single-precision 

REAL*8 

8 

8 

double-precision 

COMPLEX*8 

8 

4 

paired single¬ 
precision 

COMPLEX* 16 

DOUBLE COMPLEX 

16 

8 

paired double¬ 
precision 


An array uses the same alignment as its elements. 


NOTE 


The complex and complex* 8 data types are 4 rather than 8 byte aligned as 
they are often equivalenced to two real data types. 
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COBOL Data Types 


NOTE 


COBOL data types are defined not only to promote interlanguage operability 
but also to promote exchange of data with existing applications. 


COBOL contains five categories of data items grouped into three classes. The 
alphabetic class contains the alphabetic category. The numeric class contains the 
numeric category. The alphanumeric class contains the numeric edited, 
alphanumeric edited, and alphanumeric categories. 

■ The alignment of the group is the maximum of the alignments of its ele¬ 
ments. 

■ The elements of the group, in the order in which they appear in the source 
language, are assigned increasing positions, relative to the beginning of the 
group, in the structure representation. Each elementary item is assigned to 
the lowest available offset with the appropriate alignment. Note that this 
may require internal padding. 

■ A group's size is increased the minimum amount necessary (possibly zero) 
to make it an integral multiple of the group's alignment only if the group has 
an occurs clause. Note that this may require tail padding (only when there is 
an occurs clause). 

Level 01 and 77 items alignment may use more restrictive alignment. 

COBOL Standard Nonnumeric Data Types 

All data types that belong to the alphabetic and alphanumeric classes are 
represented as a sequence of 8-bit ASCII characters, one character per byte, with 
byte alignment. The first, or leftmost, character at the COBOL source level is the 
lowest addressed byte of the representation. 

COBOL Standard Numeric Data Types 

The data types of the numeric class are, for the purposes of this standard, dif¬ 
ferentiated primarily by the usage and sign clauses of their COBOL source 
descriptions. The numeric data types described in the ANSI standard are 
DISPLAY, PACKED-DECIMAL, BINARY, and COMPUTATIONAL. COMPUTATIONAL shall USe 

the same format as binary. 
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The implied decimal point in COBOL does not occupy a storage location. 
Numeric items described in terms of pseudo-PiCTURE character strings with no 
implied decimal point represent all such numeric items without regard to the 
implied decimal point. 

COBOL Standard Numeric Data Types — display A numeric data item described, 
explicitly or implicitly, as usage is display is represented as one ASCII decimal 
digit character for each digit position (i.e., each 9) in the picture for the item, 
aligned on a byte boundary. The high-order digit shall be the lowest addressed 
byte of the representation. The representation of ASCII decimal digits is: 


Figure 3-16: COBOL ASCII Digits 


Digit 

Decimal 

Hexadecimal 

0 

48 

30 

1 

49 

31 

2 

50 

32 

3 

51 

33 

4 

52 

34 

5 

53 

35 

6 

54 

36 

7 

55 

37 

8 

56 

38 

9 

57 

39 


Unsigned data items shall contain one byte for each digit position. 

Separate sign representations (sign is leading/trailing separate) shall be the 
ASCII plus sign (+) for nonnegative numeric values and the ASCII minus sign (-) 
for negative numeric values. The representation of the data item shall contain 
one byte for each digit position plus one byte for the sign character. The sign 
character shall be the lowest (leading) or highest (trailing) addressed byte of 
the representation. 
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Combined sign representations (sign is leading/trailing) shall combine the 
representation of the high-order (leading, most significant) or low-order (trail¬ 
ing, least significant) digit position with the operational sign for the item. A con¬ 
forming implementation for COBOL shall be able to consume data using both 
combined sign representation variants shown in the following tables and shall 
document which variant(s) is (are) produced by that implementation. 


Figure 3-17: COBOL Sign Representations, Part 1 of 2 


Nonnegative Negative 


Digit 

Decimal 

Hex 

ASCII 

Decimal 

Hex 

ASCII 

0 

123 

7B 

i 

125 

7D 

) 

1 

65 

41 

A 

74 

4A 

j 

2 

66 

42 

B 

75 

4B 

K 

3 

67 

43 

C 

76 

4C 

L 

4 

68 

44 

D 

77 

4D 

M 

5 

69 

45 

E 

78 

4E 

N 

6 

70 

46 

F 

79 

4F 

O 

7 

71 

47 

G 

80 

50 

P 

8 

72 

48 

H 

81 

51 

Q 

9 

73 

49 

I 

82 

52 

R 


NOTE 


These combined sign representations allow the translation of numeric values 
with combined signs from/to EBCDIC files without knowledge of the location 
of numeric fields within a record area. While such a capability lies outside 
ANSI X3.23-1985, which specifies that sign is separate is required when 
code set is specified for a file, current practice dictates that the exchange of 
combined sign data is necessary. 
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Figure 3-18: COBOL Sign Representations, Part 2 of 2 


Nonnegative Negative 


Digit 

Decimal 

Hex 

ASCII 

Decimal 

Hex 

ASCII 

0 

48 

30 

0 

112 

70 

p 

1 

49 

31 

1 

113 

71 

q 

2 

50 

32 

2 

114 

72 

r 

3 

51 

33 

3 

115 

73 

s 

4 

52 

34 

4 

116 

74 

t 

5 

53 

35 

5 

117 

75 

u 

6 

54 

36 

6 

118 

76 

V 

7 

55 

37 

7 

119 

77 

w 

8 

56 

38 

8 

120 

78 

X 

9 

57 

39 

9 

121 

79 

y 


NOTE 


The ABI anticipates that data fields using both representations may exist 
within a single record. Interoperability is promoted by the ability to consume 
both representations. 
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COBOL Standard Numeric Data Types — packed-decimal A numeric data item 
described explicitly as usage is packed-decimal is represented as one 4-bit 
binary coded decimal (BCD) digit for each digit position (i.e., each 9) in the pic¬ 
ture for the item. Two BCD digits are placed in each byte, with the lowest order 
digit in the most significant four bits and the operational sign representation in 
the least significant four bits of the highest addressed byte. The high-order digit 
shall be contained in the lowest addressed byte of the representation; if an even 
number of digits is specified in the picture for the item, the high-order digit shall 
be in the least significant four bits and the most significant four bits shall be zero. 
The item is aligned on a byte boundary. The digit representations are as follows: 


Digit 

Decimal 

Hexadecimal 

0 

0 

0 

1 

1 

1 

2 

2 

2 

3 

3 

3 

4 • 

4 

4 

5 

5 

5 

6 

6 

6 

7 

7 

7 

8 

8 

8 

9 

9 

9 


A conforming implementation for COBOL shall be able to consume data using 
both sign representation variants shown below and shall document which 
variant(s) is (are) produced by that implementation. 


Figure 3-19: COBOL Sign Variants 



Nonnegative 

Negative 

Unsigned 

Variant A 

OxC 

OxD 

OxF 

Variant B 

OxF 

OxD 

OxF 
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NOTE 


The ABI anticipates that data fields using both representations may exist 
within a single record. Interoperability is promoted by the ability to consume 
both representations. 


COBOL Standard Numeric Data Types — binary A numeric data item described 
explicitly as usage is binary is represented as a 16-, 32-, or 64-bit binary integer 
depending on the number of digit positions (i.e., 9's) in the picture for the item. 

If the item is signed (the picture character string contains an S) the binary 
representation is a 2's complement binary integer. The sign bit shall be the most 
significant bit of the lowest addressed byte of the binary integer. The remaining 
seven bits of the lowest addressed byte shall contain the most significant portion 
of the binary integer and the highest addressed byte shall contain the least 
significant portion of the binary integer. 

If the item has no sign, the binary representation is an unsigned binary integer. 
The lowest addressed byte shall contain the most significant portion of the binary 
integer and the highest addressed byte shall contain the least significant portion 
of the binary integer. 

As permitted by Sections 5.13.4 (9) and 5.14.4 (3) of ANSI X3.23-1985, the align¬ 
ment and size of binary data items shall be as specified in the following table: 


Figure 3-20: COBOL binary Alignments 


Digit 


Positions 

Size 

Alignment 

1-4 

16-bit 

7 VnH-p> 

5-9 

32-bit 

4 byte 

10-18 

64-bit 

4 byte 
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Binary representations of numbers that cannot be specified in the number of 
decimal digits coded in the picture for the item are nonstandard. 

COBOL Nonstandard Numeric Data Types 

Floating-point data types are not part of ANSI Standard COBOL and, therefore, 
are an optional part of this standard. A conforming implementation of COBOL 
shall adhere to ANSI/IEEE Std 754-1985 when providing these data types. 
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This section discusses the standard function calling sequence, including stack 
frame layout, register usage, parameter passing, etc. C, FORTRAN, and COBOL 
programs and their libraries use this calling sequence. The system libraries 
described in Chapter 6 require this calling sequence. 


NOTE 


C programs follow the conventions here. For specific information on the 
implementation of C, see “Coding Examples” in this chapter. 


Registers and the Stack Frame 

The MC88100 provides 32 general purpose registers, each 32 bits wide. Brief 
register descriptions appear in Figure 3-21. 


Figure 3-21: Processor Registers 


Register Name 

Usage 

#r0 

Always equal to zero 

#rl 

Holds the subroutine return pointer 

#r2 to #r9 

Temporary register set used for parameter passing 

#rl0 to #rl3 

Temporary registers used for language-specific purposes 

#rl4 to #r25 

Preserved registers 

#r26 and #r27 

Temporary registers 

#r28 and #r29 

Reserved for ABI future use 

#r30 

Preserved register 

#r31 

Contains the stack pointer 
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Some registers have assigned roles. 

#r0 Register #r0 contains the constant zero. 

#rl Register #rl contains the return pointer generated by bsr 

or jsr instructions. Register #rl may be destroyed across 
subroutine calls. 

#r2 through #r9 This set of registers may be modified across procedure 

invocations and shall therefore be presumed by the calling 
procedure to be destroyed. These temporary registers are 
used for passing parameters to the called procedure. 

#rlO through #rl3 Registers #rlO through #rl3 are also used as temporary 

registers. These registers may be destroyed across subrou¬ 
tine calls. Registers #rll,#rl2, and #rl3 have been allo¬ 
cated for some specific language requirements. Register 
#rll is used to pass the environment to a dummy pro¬ 
cedure in FORTRAN. Register #rll is also used as a 
scratch register by the dynamic linking mechanism. See 
Chapter 5 for details. Register #rl2 is used by a calling 
procedure to pass an address to a called procedure when 
the calling procedure expects a result to be stored in an 
area of memory. The called procedure shall return its 
result in this area pointed to by the value in #rl2, while 
the size in bytes is passed in #rl3, if required by the 
language. 

#rl4 through #r25 This set of registers shall be saved by the called procedure. 

They are used when values must be preserved for the 
duration of the current routine. 

#r26 and #r27 This set of registers may be modified across procedure 

invocations and shall therefore be presumed by the calling 
procedure to be destroyed. 

#r28 and #r29 A conforming program shall neither change nor rely on 

the contents of these registers. 

#r30 Register #r30 is a preserved register and shall be saved by 

the called procedure. 
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#r31 The stack pointer (stored in #r31) shall maintain 16-byte 

alignment. It shall point to the last word allocated on the 
stack, and grow towards low addresses. If required, it 
shall be decremented by the called procedure and incre¬ 
mented prior to returning. 

Registers #rl4 through #r25 and #r30, which are visible to both a calling and a 
called function, // belong" to the calling function. In other words, a called func¬ 
tion shall save these registers' values before it changes them, restoring their 
values before it returns. Registers #rl through #rl3, #r26, and #r27 "belong" 
to the called function. If a calling function wants to preserve such a register 
value across a function call, it must save the value in its local stack frame. 

Signals can interrupt processes [see signal(BA_OS)]. Functions called during 
signal handling have no unusual restrictions on their use of registers. A compiler 
may generate code that causes programs to use any register without the danger 
of signal handlers inadvertently changing their values. 

In addition to the registers, each function may have a frame on the run-time 
stack. This stack grows downward from high addresses. Figure 3-22 shows the 
stack frame organization. 
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Figure 3-22: Stack Organization 


High 

Address 


Argument Area 


SP' —> 
(SP before call) 


Temporary Space/ 
Local Variable Space 


direction of 
stack growth 




Argument Area 


SP—> 
(SP after call) 


Low 

Address 


SP denotes the stack pointer of the called subroutine at entry while SP' denotes 
the stack pointer of the calling subroutine at entry. 

Several key points about the stack frame deserve mention. 
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■ The stack pointer shall maintain 16-byte alignment. 

■ The stack pointer shall point to the last word allocated on the stack and shall 
grow towards low addresses. 

■ The stack pointer shall be decremented by the called procedure on entry, if 
required, and incremented prior to return. 

■ Other areas depend on the compiler and the code being compiled. The stan¬ 
dard calling sequence does not define a maximum stack frame size, nor does 
it restrict how a language system uses the "local variable space" of the stan¬ 
dard stack frame. 

■ The argument area shall be allocated by the caller and shall be at least 32 
bytes. Its contents are not preserved across calls. 

■ The presence of the temporary space/local variable space depends on the 
nature of the function. 

Across function boundaries, the function prologue may consist of several opera¬ 
tions that depend on the nature of the function. Stack space may be allocated if 
the function: 

■ Uses the preserved registers and therefore must save and restore them 

■ Calls another function and therefore must save #rl, allocate the argument 
area, and possibly save any parameters. 

■ Needs local variables or temporary space. 

The standard function prologue performs any or all of the following tasks, as 
needed: 

■ Allocates stack space 

■ Saves #rl 

■ Saves the address of the memory return value passed in #rl2 

■ Saves parameters passed in registers #r2-#r9 

■ Saves registers #rl4 through #r25 
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Figure 3-23 illustrates an example of the function prologue allocating 88 bytes for 
local storage, and saving registers #r24 and #r25. Eighty bytes are for local 
storage, and an additional 8 bytes are used for saving registers #r24 and #r25. 


Figure 3-23: Function Prologue 


fen: 


subu 

#r31,#r31,96 

st .d 

#r24,#r31,88 


The standard function epilogue performs the following tasks, as needed: 

■ Either loads the return value or copies the result to the area pointed to by the 
pointer received in #rl2 

■ Restores registers #rl4 through #r25 and #r30 

■ Deallocates local stack space 

If the function returns no value, or if the return register(s) already contain(s) the 
desired value, and no local stack was allocated, the epilogue in Figure 3-24 would 
suffice. 


Figure 3-24: Simple Function Epilogue 


fcnend: 

jmp #rl 


For a function that uses register #r25, is not a leaf function (i.e., may call another 
function and therefore may modify #rl), and requires a total of 80 bytes of local 
stack space, the following epilogue might be used: 
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Figure 3-25: Function Epilogue 


fcnend: 


Id 

#r25,#r31,72 

Id 

#rl, #r31,76 

addu 

#r31,#r31,80 

jmp 

#rl 


Argument Transmission 

There is an offset in the argument area corresponding to each argument. The cal¬ 
ling procedure shall use the offset as if all of the parameters were passed in 
memory with the first parameter at offset zero, and subsequent parameters 
passed consecutively. The offset is always rounded up to a multiple of 4 bytes. 
For arguments with greater than 4-byte alignment, the offset is always rounded 
up to a multiple of that alignment. 

Arguments shall be at least word-aligned objects, and shall always be an integral 
number of words long. The first 8 words of the argument list will be passed in 
registers #r2 through #r9, and not in the argument area. The first word of the 
argument list is passed in #r2, the second in #r3, etc., allocating registers con¬ 
secutively until the eighth word is passed in #r9. The remainder of the argu¬ 
ment list will be passed in memory, starting at an offset of 8 words from the start 
of the argument area. 

The following subsections detail the mapping from the requirements of the 
specific language to the rules listed here, and also specify special cases that form 
exceptions to the rules stated here. 
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Argument Transmission for C 

For the language C, signed short and characters are sign-extended to 32 bits 
before being passed. Unsigned short and characters are zero-extended to 32 bits 
before being passed. Any pointer, floating-point, integer, 4-byte aligned 4-byte 
structure, or 4-byte aligned 4-byte union argument whose offset is less than 32, is 
passed in the register numbered (or, for double-precision, the register pair begin¬ 
ning with the register numbered) 2+(offset /4). 

All other arguments are passed at offset bytes from the beginning of the argument 
area. 

Argument Transmission for FORTRAN 

All actual arguments are passed by reference, i.e., a pointer to the argument is 
passed. Values transmitted in the argument area whose offset is less than 32 are 
passed in registers. 

A procedure argument is represented by a 4-byte aligned instance of the follow¬ 
ing structure: 

struct proc {int entry; int envir;} 

where entry is the address of the first instruction of the procedure, and envir is 
the "environment" for the procedure. 

For an actual argument that is a procedure, the address of a proc structure 
instance is passed. The envir member of this structure is unspecified; a value of 
zero is recommended. 

When a dummy procedure is invoked, control is transferred to the address in the 
entry member of the associated proc structure instance. At time of transfer, 
register #rll contains the content of the envir member of the structure instance. 
Otherwise, the rules for dummy procedure invocation are the same as for exter¬ 
nal procedure invocation. 


LOW-LEVEL SYSTEM INFORMATION 


3-25 



Function Calling Sequence 


NOTE 


The representation of a procedure includes an environment in order to pro¬ 
vide interoperability with languages that have internal procedures. 


The FORTRAN character data type requires the passing of length as well as data 
address. In order to keep the other fundamental data types in compliance with 
the general rules outlined in the "Argument Transmission" section and to pro¬ 
mote interoperability with other languages, FORTRAN establishes the length 
information for each string after passing all other arguments (including the char¬ 
acter data addresses). The length in bytes of each character argument is passed 
as a 32-bit quantity at a position in the argument area based on the following for¬ 
mula: 


given: argl , arg2, .. argC ,..., argN as the actual argument list 

where: argC is of type character; there are N actual arguments total, 

and argC is the Cth argument 

then: the length of argC will be passed with offset 4N+4(C-1). 

If argC is the last actual argument of type character, the argu¬ 
ment area shall be at least 4N+4C bytes in size. If argX is the Xth 
actual argument and is not of type character, the value at offset 
4N+4(X-1) is undefined. 


Argument Transmission for COBOL 

The argument transmission for all data types is done by passing the address of 
the argument according to the convention outlined in the general rules of the 
"Argument Transmission" section. 


Result Transmission 

Results may be returned in registers or in memory. Registers #r2 through #r9 
are available to return results. When results are returned in memory, the calling 
procedure allocates such memory and passes a pointer to it in #rl2. The called 
procedure will then perform the copy to this area. If the language requires a size 
for this area, then the size in bytes shall be passed in #r!3. 
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Other data types are returned by copying the return value to the memory area 
pointed to by the address contained in #r 12 at subroutine entry. 

The following subsections detail the mapping from the requirements of each 
specific language to the rules specified in this section, and also specify special 
cases that form exceptions to the rules stated here. 

Result Transmission for C 

In the language C, single-precision floating-point, pointers, 4-byte aligned 4-byte 
structures, and 4-byte aligned 4-byte unions are returned in #r2. Signed integers 
and characters are sign-extended to 32 bits and returned in #r2. Unsigned 
integers and characters are zero-extended to 32 bits and returned in #r2. 
Double-precision floating-point values are returned in the register pair #r2 and 
#r3. Other types are returned via memory as described in the general rules of 
"Result Transmission." 

A function declared to return a float returns a single-precision value. 

Result Transmission for FORTRAN 

FORTRAN follows the general rules outlined in "Result Transmission" with the 
following additions. 

integer variant data types of size less than 4 bytes are sign-extended to 4 bytes 
before being returned, logical variant data types of size less than 4 bytes are 
extended to 4 bytes before being returned. 

One word results are returned in register #r2. double precision and real*8 
results are returned in registers #r2 and #r3. 

complex, complex* 8, complex* 16, and double complex functions return their 
result by placing the data in memory at the location addressed by register #rl2 
(on entry to the function). The value in register #rl3 (on entry to the function) is 
unused. 

character functions return their result by placing the data in memory at the loca¬ 
tion addressed by register #rl2 (on entry to the function) padded or truncated to 
the length in bytes of the data area given by register #rl3 (on entry to the func¬ 
tion). 
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Calls to fixed-sized character functions, as well as those to character* (*) func¬ 
tions, pass the length in #rl3. 


NOTE 


This method does not interoperate with C structure returning functions 
except when the size of the structure is known to equal the value of #rl3. 


Result Transmission for COBOL 

There are no value-returning functions in COBOL. 
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Virtual Address Space 

Processes execute in a 32-bit virtual address space. Memory management 
hardware translates virtual addresses to physical addresses, hiding physical 
addressing and letting a process run anywhere in the system's real memory. 
Processes typically begin with three logical segments, commonly called text, data, 
and stack. As Chapter 5 describes, dynamic linking creates more segments dur¬ 
ing execution, and a process can create additional segments for itself with system 
services. 

Page Size 

Memory is organized by pages, which are the system's smallest units of memory 
allocation. Page size can vary from one system to another. The allowable page 
sizes are 4K, 8K, 16K, 32K, or 64K. Processes can call sysconf (BA_OS) to deter¬ 
mine the system's current page size. 

Virtual Address Assignments 

Conceptually, processes have the full 32-bit address space available. In practice, 
however, several factors limit the size of a process. 

■ The system reserves a configuration-dependent amount of virtual space. 

■ A tunable configuration parameter limits process size. 

■ A process whose size exceeds the system's available, combined physical 
memory and secondary storage cannot run. Although some physical 
memory must be present to run any process, the system can execute 
processes that are bigger than physical memory, paging them to and from 
secondary storage. Nonetheless, both physical memory and secondary 
storage are shared resources. System load, which can vary from one pro¬ 
gram execution to the next, affects the available amounts. 
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Figure 3-26: Virtual Address Configuration 


End of memory 


Beginning of memory 


Oxffffffff 


Reserved 

Stack and 
dynamic segments 


Loadable segments 


Loadable segments 

Processes' loadable segments may begin at 0. The exact 
addresses depend on the executable file format (see Chapters 4 
and 5). 

Stack and dynamic segments 

A process's stack and dynamic segments reside below the 
reserved area. Processes can control the amount of virtual 
memory allotted for stack space, as described below. 

Reserved A reserved area resides at the top of virtual space. 


NOTE 


Although application programs may begin at virtual address 0, they conven¬ 
tionally begin above 0x10000 (64K), leaving the initial 64K with an invalid 
address mapping. Processes that reference this invalid memory (for exam¬ 
ple, by dereferencing a null pointer) generate an access exception trap, as 
described in the “Exception Interface” section of this chapter. 


As the figure shows, the system reserves the high end of virtual space, with a 
process's stack and dynamic segments below that. Although the exact boundary 
between the reserved area and a process depends on the system's configuration, 
the reserved area shall not consume more than 512 MB from the virtual address 
space. Thus the user virtual address range has a minimum upper bound of 
Oxdf f f f f f f. Individual systems may reserve less space, increasing processes' 
virtual memory range. More information follows in the section "Managing the 
Process Stack." 
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Although applications may control their memory assignments, the typical 
arrangement follows the diagram above. Loadable segments reside at low 
addresses; dynamic segments occupy the higher range. When applications let 
the system choose addresses for dynamic segments (including shared object seg¬ 
ments), it chooses high addresses. This leaves the "middle" of the address spec¬ 
trum available for dynamic memory allocation with facilities such as 
malloc(BA_OS). 

Managing the Process Stack 

Section "Process Initialization" in this chapter describes the initial stack contents. 
Stack addresses can change from one system to the next—even from one process 
execution to the next on a single system. Processes, therefore, should not depend 
on finding their stack at a particular virtual address. The stack segment has read 
and write permissions. 

A tunable configuration parameter controls the system maximum stack size. A 
process also can use setrlimit(BA_OS), to set its own maximum stack size, up 
to the system limit. Changes in the stack virtual address and size affect the vir¬ 
tual addresses for dynamic segments. Consequently, processes should not 
depend on finding their dynamic segments at particular virtual addresses. Facili¬ 
ties exist to let the system choose dynamic segment virtual addresses. 

Coding Guidelines 

Operating system facilities, such as mmap(KE_OS), allow a process to establish 
address mappings in two ways. First, the program can let the system choose an 
address. Second, the program can force the system to use an address the pro¬ 
gram supplies. This second alternative can cause application portability prob¬ 
lems, because the requested address might not always be available. Differences 
in virtual address space can be particularly troublesome between different archi¬ 
tectures, but the same problems can arise within a single architecture. 

Processes' address spaces typically have three segment areas that can change size 
from one execution to the next: the stack [through setrlimit (BA_OS)], the data 
segment [through malloc(BA_OS)], and the dynamic segment area [through 
ramap(KE_OS)]. Consequently, an address that is available in one process execu¬ 
tion might not be available in the next. A program that used ramap(KE_OS) to 
request a mapping at a specific address thus could appear to work in some 
environments and fail in others. For this reason, programs that wish to establish 
a mapping in their address space should let the system choose the address. 
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Despite these warnings about requesting specific addresses, the facility can be 
used properly. For example, a multiprocess application might map several files 
into the address space of each process and build relative pointers among the files' 
data. This could be done by having each process ask for a certain amount of 
storage at an address chosen by the system. After each process receives its own, 
private address from the system, it would map the desired files into memory, at 
specific addresses within the original area. This collection of mappings could be 
at different addresses in each process but their relative positions would be fixed. 
Without the ability to ask for specific addresses, the application could not build 
shared data structures, because the relative positions for files in each process 
would be unpredictable. 


Processor Execution Modes 


Two execution modes exist in the M88000 architecture: user and supervisor. 
Processes run in user mode (the less privileged). The operating system kernel 
runs in supervisor mode. A program executes a trap instruction to change execu¬ 
tion modes. 


NOTE 


The ABI does not define the implementation of individual system calls. 
Instead, programs shall use the system libraries that Chapter 6 describes. 
Programs with embedded system call trap instructions do not conform to the 
ABI. 


Exception interface 

As the MC88100 User's Manual describes, instruction execution can generate 
exceptions. The operating system handles such an exception either by complet¬ 
ing the faulting operation in a manner transparent to the application, or by 
delivering a signal to the application. The correspondence between exceptions 
and signals is given in Figures 3-27 and 3-28. 

The signals that an exception may give rise to are sigsegv, sigill, sigbus, 
sigtrap, and sigfpe. If one of these signals is generated due to an exception 
when the signal is blocked, the behavior is undefined. 
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Due to the pipelined nature of the MC88100, more than one instruction may be 
executing concurrently. When an exception occurs, the operating system causes 
all executing instructions to complete their executions. As a result of completing 
these executions, additional exceptions may be generated. At most one of these 
concurrent exceptions is a precise exception; all the others are necessarily impre¬ 
cise. 

The operating system partitions the set of concurrent exceptions into subsets, all 
of whose exceptions share the same signal number. Each subset of exceptions is 
delivered as a single signal. The multiple signals resulting from multiple con¬ 
current exceptions are delivered in unspecified order, except that, if there is a 
precise exception among the concurrent exceptions, the signal corresponding to 
the precise exception shall be delivered first. 

When a signal representing an exception is delivered and the extended signal 
handler interface is selected with the sajsiginfo sigaction(BA_OS) flag, the 
information communicated through the second and third arguments is as fol¬ 
lows. In the siginfo structure, si signo contains the signal number; 
si_machinexcep contains the value 1;_ncodes contains the number of con¬ 
current exceptions associated with this signal; _exblks points to an array of 
exblk t structures consisting of ncodes elements; and si code contains a code 
identifying the cause of the signal. In each of the exblk t elements, eb_signo 
contains the signal number; eb_code contains the code for the particular kind of 
exception, as indicated in Figures 3-27 and 3-28; and the_eb_registers union 
contains additional information about the exception, as indicated in Figures 3-27 
and 3-28. In the mcontext_t structure of the ucontext_t structure, version 
contains the value 1; and the gregs array contains values for the indicated regis¬ 
ters at the point of the exception. The effects of an instruction in progress at the 
time of the exception, including changes to registers and memory, are reflected in 
the machine state if and only if the given instruction completed successfully. For 
a precise exception, the value of the r xip element, with its low two bits cleared, 
locates the instruction generating the exception. 

When a signal not representing an exception is delivered and the extended signal 
handler interface is selected with the sa siginfo sigaction flag, the 
si_machinexcep member of the siginfo structure has the value 0. 

Return from a signal handler handling a signal corresponding to an exception is 
permitted. The process state for resumption is that contained in the ucontext_t 
structure. In particular, the machine state for resumption is that contained in the 
(possibly modified) gregs array of the mcontext_t structure. Note that process 
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execution is resumed at the addresses specified by the r nip and r fip values; 
the r xip value is ignored. Note also that the low two bits of the aforementioned 
register values are interpreted on resumption. See the MC88100 User's Manual for 
details. 

Figures 3-27 and 3-28 show the relationship between machine exceptions and sig¬ 
nals. The "Exception" column indicates the machine exception; see the MC88100 
User's Manual for more details. The "P/I" column indicates whether the excep¬ 
tion is precise ("P") or imprecise ("I"); see the MC88100 User's Manual for more 
details. The "Signal" column indicates the signal number under which the 
exception is delivered, if it is delivered. The "eb_code" column indicates the 
value assigned to the eb code member of the exblk t structure for the excep¬ 
tion, when the siginf o structure is passed to the signal handling function. The 
eb_registers column indicates which member of the_eb_registers union is 
present, if any, when the siginf o structure is passed to the signal handling func¬ 
tion. 
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Figure 3-27: Exceptions and Signals, Part 1 of 2 
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Figure 3-28: Exceptions and Signals, Part 2 of 2 
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Notes: 

1. Code access exceptions caused by demand paging within the text segment 
and areas made executable [as by mprotect (KE_OS)] are handled tran¬ 
sparently to the application. 

2. Data access exceptions caused by references to the stack segment shall be 
handled by extending the stack in a manner transparent to the application, 
within the stack limits specified by setrlimit (BA_OS). Data access 
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exceptions caused by demand paging shall be handled transparently to the 
application. 

3. The values of the members of struct df ltinfo, passed as _eb_registers, 
are the MC88100's Address Register, Transaction Register, and Data Register, 
respectively, of the memory transaction that caused the fault. 

4. This exception can be disabled by setting the MXM bit of the Processor 
Status Register. (See the setpsr() function in "Support Routines" in 
Chapter 6.) 

5. Conforming applications shall not use unimplemented opcodes. 

6. If the faulting instruction is div, the dividend is the most negative integer 
and the divisor is -1, then the sigfpe signal shall be sent with fpe_intovf 
as eb_code. If the divisor is zero for any integer division instruction, the 
sigfpe signal shall be sent with fpe intdiv as eb_code. Otherwise, the 
faulting instruction must be div and one or both operands negative. In 
this case, the system completes the operation in a manner transparent to 
the application. 

7. This exception can be disabled by clearing bit 0 (EFINX) of the Floating 
Point Control Register. 

8. The values of the members of struct fpifltinfo, passed as 
_eb_registers, are the MC88100's Floating Point Result High Register, 
Result Low Register, and Imprecise Operation Type Register, respectively. 

9. If bit 1 (EFOVF) of the FPCR is set, the sigfpe signal shall be sent with 
fpe fltovf as eb_code. Otherwise, bit 1 (AFOVF) of the FPSR shall be set, 
and if bit 0 (EFINX) of the FPCR is set, the sigfpe signal shall be sent with 
fpe_fltinex as eb_code. If bit 0 of the FPCR is also clear, then bit 0 
(AFINX) of the FPSR shall be set and the system shall complete the opera¬ 
tion in a manner transparent to the application and consistent with 
ANSI/IEEE Std 754-1985 and the MC88100 User's Manual . 

10. If bit 2 (EFUNF) of the FPCR is set, the sigfpe signal shall be sent with 

fpe_fltund as eb_code. Otherwise, if there has been a loss of accuracy, bit 
2 (AFUNF) of the FPSR shall be set. In this case, if bit 0 (EFINX) of the FPCR 
is set, the sigfpe signal shall be sent with fpe_fltinex as eb_code; if it is 
clear, then bit 0 (AFINX) of the FPSR shall be set. If no signal is sent, the 
system shall complete the operation in a manner transparent to the appli¬ 
cation and consistent with ANSI/IEEE Std 754-1985 and the MC88100 User's 
Manual. 
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11. If the numerator is zero, the exception shall be handled as a floating-point 
reserved operand exception. Otherwise, if bit 3 (EFDVZ) of the FPCR is set, 
the sigfpe signal shall be sent with fpe_fltdiv as eb_code. If bit 3 of the 
FPCR is clear, then the system shall set bit 3 (AFDVZ) of the FPSR and com¬ 
plete the operation in a manner transparent to the application and con¬ 
sistent with ANSI/IEEE Std 754-1985 and the MC88100 User's Manual. 

12. If the operation is the subtraction of two infinities, the multiplication of 
infinity and zero, or the division of one infinity by another, and bit 4 
(EFINV) of the FPCR is set, then the sigfpe signal shall be sent with 
fpe_fltoperr as eb_code; otherwise bit 4 (AFINV) of the FPSR shall be set. 
If either operand is a signaling NaN and bit 4 of the FPCR is set, then the 
sigfpe signal shall be sent with fpe_fltnan as eb_code; otherwise bit 4 of 
the FPSR shall be set. If no signal is sent, the system shall complete the 
operation in a manner transparent to the application and consistent with 
ANSI/IEEE Std 754-1985 and the MC88100 User's Manual. 

13. If the operand can be converted to an integer without overflow, the system 
shall complete the operation in a manner transparent to the application. If 
it cannot, and bit 4 (EFINV) of the FPCR is set, then the sigfpe signal shall 
be sent. If bit 4 of the FPCR is clear, then bit 4 (AFINV) of the FPSR shall be 
set and the system shall complete the operation in a manner transparent to 
the application and consistent with ANSI/IEEE Std 754-1985. 


Process Initialization 


This section describes the machine state that exec(BA_OS) creates for "infant" 
processes, including argument passing, register usage, stack frame layout, etc. 
Programming language systems use this initial program state to establish a stan¬ 
dard environment for their application programs. As an example, a C program 
begins executing at a function named main, conventionally declared in the fol¬ 
lowing way. 
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Figure 3-29: Declaration for main 


extern int main(int argc, char *argv[], char *envp[]); 


Briefly, argc is a non-negative argument count; argv is an array of argument 
strings, with argv [argc] ==0; and envp is an array of environment strings, also 
terminated by a null pointer. 

Although this section does not describe C program initialization, it gives the 
information necessary to implement the call to main or to the entry point for a 
program in any other language. 

Registers 

When a process is first entered (from an exec() system call), registers are initial¬ 
ized as follows: 

#rl is implementation-defined. 

#r2 contains argc , the number of arguments. 

#r3 contains argv, a pointer to the array of argument pointers in the stack. 

The array is immediately followed by a NULL pointer. If there are no 
arguments, #r3 shall point to a NULL pointer. 

#r4 contains envp, a pointer to the array of environment pointers in the 

stack. The array is immediately followed by a NULL pointer. If no 
environment exists, #r4 shall point to a NULL pointer. 

#r5 contains a pointer to the auxiliary vector. The auxiliary vector shall 

have at least one member, a terminating entry with an a_type of 
AT_NULL. 

#r6 possibly contains a termination function pointer. If #r6 contains a 

nonzero value, the value represents a function pointer that the appli¬ 
cation should register with atexit (BA_OS). If #r6 contains zero, no 
action is required. 
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#r7-#rl3 

are currently set to zero. Future versions of the system might use the 
registers to hold special values, so applications should not depend on 
these registers' values. 

#rl4-#r30 

are unspecified. 

#r31 is the initial stack pointer, aligned to an 16-byte boundary. 

FPSR is the floating-point user status register. This register is initially 
cleared. 

FPCR is the floating-point user control register. This register is set to round 
to nearest mode and all the user exception handlers are disabled. Indi¬ 
vidual processes may change the register contents if desired. 

PSR is the Processor Status Register; it contains 0x3f0, which corresponds 

to: 


■ user mode, 

■ Big-Endian byte ordering, 

■ concurrent operation allowed, 

■ carry bit clear, 

■ SFU 1 enabled, 

■ SFU2-SFU7 disabled, 

■ misaligned accesses cause an exception, 
S interrupts enabled, 

■ shadow registers enabled. 


Individual programs may need to manipulate the stacked data and register con¬ 
tents at startup before control passes to the main section of the program. 
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Process Stack 

Every process has a stack, but the system defines no fixed stack address. Further¬ 
more, a program's stack address can change from one system to another—even 
from one process invocation to another. 

Whereas the argument and environment vectors transmit information from one 
application program to another, the auxiliary vector conveys information from 
the operating system to the program. This vector is an array of the following 
structures, interpreted according to the a type member. 


Figure 3-30: Auxiliary Vector 


typedef 

struct 



{ 

int 

a_type; 



union { 

long 

a val; 



void 

*a_ptr; 



void 

(*a_fcn) () ; 


} a un; 



} auxv t; 
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Figure 3-31: Auxiliary Vector Types, a type 


Name 

Value 

a un 

AT_NULL 

0 

ignored 

AT_IGNORE 

1 

ignored 

at_execfd 

2 

a_val 

AT_PHDR 

3 

a_ptr 

AT_PHENT 

4 

a_val 

AT PHNUM 

5 

a val 

AT_PAGESZ 

6 

a val 

ATJBASE 

7 

a_ptr 

AT_FLAGS 

8 

a val 

AT_ENTRY 

9 

a_ptr 


AT NULL 


AT IGNORE 


AT EXECFD 


AT PHDR 


The auxiliary vector has no fixed length; instead the end of the 
table is indicated by placing at_null into a_type. 

This type indicates the entry has no meaning. The correspond¬ 
ing value of a_un is undefined. 

As Chapter 5 describes, exec(BA_OS) may pass control to an 
interpreter program. When this happens, the system places 
either an entry of type at execfd or one of the type at phdr in 
the auxiliary vector. The entry for type at_execfd uses the 
a_val member to contain a file descriptor open to read the 
application program's object file. 

Under some conditions, the system creates the memory image 
of the application program before passing control to the inter¬ 
preter program. When this happens, the ajptr member of the 
at phdr entry tells the interpreter where to find the program 
header table in the memory image. If the at_phdr entry is 
present, entries of types at_phent, at_phnum, and at_entry shall 
also be present. See Chapter 5 in both the System V ABI and 
this processor supplement for more information about the pro¬ 
gram header table. 
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AT_PHENT 

AT PHNUM 

AT_PAGESZ 

AT_BASE 

AT_FLAGS 

AT ENTRY 


The a val member of this entry holds the size, in bytes, of one 
entry in the program header table to which the at_phdr entry 
points. 

The a val member of this entry holds the number of entries in 
the program header table to which the atjphdr entry points. 

If present, this entry's a_val member gives the system page 
size, in bytes. The same information also is available through 
sysconf (BA_OS). 

The a ptr member of this entry holds the base address at which 
the interpreter program was loaded into memory. See "Pro¬ 
gram Header" in the System V ABI for more information about 
the base address. 

If present, the a_val member of this entry holds one-bit flags. 
Bits with undefined semantics are set to zero. No flags are 
defined for the M88000. 

The a_ptr member of this entry holds the entry point of the 
application program to which the interpreter program should 
transfer control. 


Other auxiliary vector types are reserved. 
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This section discusses example code sequences for fundamental operations such 
as calling functions, accessing static objects, and transferring control from one 
part of a program to another. Previous sections discuss how a program may use 
the machine or the operating system, and they specify what a program may and 
may not assume about the execution environment. Unlike previous material, the 
information here illustrates how operations may be done, not how they must be 
done. 

As before, examples use the ANSI C language. Other programming languages 
may use the same conventions displayed below, but failure to do so does not 
prevent a program from conforming to the ABI. Two main object code models 
are available. 

■ Absolute code. Instructions can hold absolute addresses under this model. To 
execute properly, the program must be loaded at a specific virtual address, 
making the program's absolute addresses coincide with the process's virtual 
addresses. 

■ Position-independent code. Instructions under this model hold relative 
addresses, not absolute addresses. Consequently, the code is not tied to a 
specific load address, allowing it to execute properly at various positions in 
virtual memory. 

Following sections describe the differences between these models. Code 
sequences for the models (when different) appear together, allowing easier com¬ 
parison. 


NOTE 


Examples below show code fragments with various simplifications. They are 
intended to explain addressing modes, not to show optimal code sequences 
nor to reproduce compiler output. 
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NOTE 


When other sections of this document show assembly language code 
sequences, they typically show only the absolute versions. Information in 
this section explains how position-independent code would alter the exam¬ 
ples. 


Code Model Overview 

When the system creates a process image, the executable file portion of the pro¬ 
cess has fixed addresses, and the system chooses shared object virtual addresses 
to avoid conflicts with other segments in the process. To maximize text sharing, 
shared object libraries conventionally use position-independent code, in which 
instructions contain no absolute addresses. Shared object text segments can be 
loaded at various virtual addresses without having to change the segment 
images. Thus multiple processes can share a single shared object text segment, 
even though the segment resides at a different virtual address in each process. 

Position-independent code relies on two techniques. 

■ Control transfer instructions hold addresses relative to the Execute Instruc¬ 
tion Pointer (XIP). A XIP-relative branch or function call computes its desti¬ 
nation address in terms of the current XIP, not relative to any absolute 
address. 

■ When the program requires an absolute address, it computes the desired 
value. Instead of embedding absolute addresses in the instructions, the com¬ 
piler generates code to calculate an absolute address during execution. 

Because the processor architecture provides XIP-relative call and branch instruc¬ 
tions, compilers can satisfy the first condition easily. 

A global offset table and a procedure linkage table provide information for address 
calculation. Position-independent object files (executable and shared object files) 
have these tables in unshared segments. When the system creates the memory 
image for an object file, the table entries are relocated to reflect the absolute vir¬ 
tual addresses as assigned for an individual process. Because unshared segments 
are private for each process, the table entries can change—unlike shared seg¬ 
ments, which multiple processes share. 
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However, there still remains the problem of addressing the global offset table 
and the procedure linkage table in a position-independent manner. The M88000 
architecture lacks instructions to reference data or compute addresses with XIP- 
relative addresses. The most efficient method to reference locations in a shared 
object is with based addressing. In this scheme, the address of the shared object 
is computed at execution time and held in a register. The offset from this address 
to any location in the shared object is known by the link editor when it is building 
the shared object, and this offset can be efficiently encoded in instructions. 

In order to allow it to lay out the shared object as efficiently as possible, the link 
editor is given the responsibility of choosing the location in the shared object 
whose address at execution time will serve as the addressing base. Code gen¬ 
erated for a shared object refers to the addressing base only indirectly, through a 
variety of relocation types that deal with the addressing base. The link editor 
records its choice of addressing base with the dt_88k_addrbase value. (See 
Chapter 5 for more information.) One natural choice for the position of the 
addressing base is the address of the global offset table. 

Do not confuse the related terms "base address" and "addressing base." The 
base address of an executable or shared object file, as defined by the System V 
ABI, is the lowest virtual address associated with the memory image of the 
program's object file. In similar terms, the addressing base is a particular virtual 
address associated with the memory image of the program's object file. The 
addressing base of a shared object may coincide with its base address, but it need 
not. 

Assembly language examples below show the explicit notation needed for 
position-independent code. In the descriptions below, the construction "differ¬ 
ence between X and Y" means the 32-bit modulus subtraction X - Y. 

s#got This expression denotes the address of a global offset table entry 

for symbol s. 

p#gotp This expression denotes the address of a global offset table pro¬ 

cedure entry for the procedure named by symbol p. 

p#pit This expression denotes an address to which control can be 

transferred to invoke the procedure named by symbol p. This 
address is either the address of p or the address of a procedure 
linkage table entry for p. 


3-46 


Motorola 88000 PROCESSOR ABI SUPPLEMENT 



Coding Examples 


s#rel 


s#got_rel 


p#gotp_rel 


p#plt_rel 


s#abdiff 


This expression denotes the difference between the value of the 
symbol s and the addressing base for the shared object containing 
the expression. This expression is valid only in a shared object. 

This expression denotes the difference between the address 
denoted by s#got and the addressing base for the shared object 
containing the expression. This expression is valid only in a 
shared object. 

This expression denotes the difference between the address 
denoted by p#gotp and the addressing base for the shared object 
containing the expression. This expression is valid only in a 
shared object. 

This expression denotes the difference between the address 
denoted by p#pit and the addressing base for the shared object 
containing the expression. This expression is valid only in a 
shared object. 

This expression denotes the difference between the addressing 
base for the shared object containing the expression and the value 
of the symbol s . The value of the symbol s must represent an 
address in the shared object containing the expression. This 
expression is valid only in a shared object. 


Position-Independent Function Prologue and 
Epilogue 

This section describes the function prologue and epilogue for position- 
independent code. A position-independent function generally needs to establish 
its addressing base to afford access to its private data, in particular its global 
offset table entries. The addressing base is typically computed into a preserved 
register, such as #r25, so that its value will be preserved throughout the activa¬ 
tion of the function. 
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NOTE 


As a reminder, this entire section contains examples. Using #r25 is a con¬ 
vention, not a requirement; moreover, this convention is private to a function. 
Not only could other registers serve the same purpose, but different func¬ 
tions in a program could use different registers. 


The prologue for a position-independent function name that needs 96 bytes of 
stack space and uses register #r25 to hold the addressing base might be as shown 
in Figure 3-32. 


Figure 3-32: Position-Independent Function Prologue 


name: subu 

#r31,#r31,96 

St 

#r25,#r31,88 

st 

#rl,#r31,92 

bsr.n 

here 

or .u 

#r25,#r0,#hil6(here#abdiff) 

here: or 

#r25,#r25,#lol6(here#abdiff) 

addu 

#r25,#r25,#rl 


The epilogue for the position-independent function name described above might 
be as shown in Figure 3-33. 


Figure 3-33: Position-Independent Function Epilogue 


name: 

Id 

#r25,#r31,88 


Id 

#rl,#r31,92 


addu 

#r31,#r31,96 


jmp 

#rl 
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Data Objects 

This discussion excludes stack-resident objects, because programs always com¬ 
pute their virtual addresses relative to the stack and frame pointers. Instead, this 
section describes objects with static storage duration. 

In the M88000 architecture, only load and store instructions access memory. 
Because instructions cannot hold 32-bit addresses directly, a program normally 
computes an address into a register. Symbolic references in absolute code put 
the symbols' values—or absolute virtual addresses—into instructions. 


Figure 3-34: Absolute Load and Store 

C Assembly 


global 

src, dst, ptr 

or .u 

#r2,#r0,#hil6(dst) 

or 

#r2,#r2,#lol6(dst) 

or.u 

#r3,#r0,#hil6(ptr) 

St 

#r2,#r3,#lol6(ptr) 

or.u 

#r2,#r0,#hil6(src) 

Id 

#r2,#r2,#lol6(src) 

or.u 

#r3,#r0,#hil6(ptr) 

Id 

#r3,#r3,#lol6(ptr) 

St 

#r2,#r3,0 



Position-independent instructions cannot contain absolute addresses. Instead, 
instructions that reference symbols hold the offsets of the symbols' global offset 
table entries relative to the addressing base for the shared object. Combining the 
offset of the global offset table entry with the addressing base in #r25 gives the 
absolute address of the table entry holding the desired address. 
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Figure 3-35: Position-Independent Load and Store 



Assembly 


global src, dst, ptr 


or.u #r2,#r0,#hil6(dst#got_rel) 

or #r2,#r2, #lol6(dst#got_rel) 

Id #r2,#r25,#r2 

or.u #r3,#r0,#hil6(ptr#got_rel) 

or #r3,#r3,#lol6(ptr#got_rel) 

Id #r3,#r25,#r3 

st #r2,#r3, 0 

or.u #r2,#r0,#hil6(src#got_rel) 

or #r2,#r2, #lol6(src#got_rel) 

Id #r2,#r25,#r2 

Id #r2,#r2 f 0 

or.u #r3, #rO f #hil6(ptr#got_rel) 

or #r3, #r3 f #lol6(ptr#got_rel) 

Id #r3,#r25,#r3 

Id #r3,#r3 f 0 

st #r2,#r3,0 


Function Calls 


A function call is typically made with a bsr instruction. A bsr instruction has a 
self-relative branch displacement that can reach 128 megabytes in either direc¬ 
tion. Hence, use of a bsr instruction to effect a call within an executable or 
shared object file limits the size of the executable or shared object file to 128 
megabytes. A bsr instruction can also be used to effect a call between two dif¬ 
ferent object files, without constraining the placement of the two object files in 
memory, because control generally passes from the bsr instruction, through an 
indirection sequence, to the desired destination. See "Procedure Linkage Table" 
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in Chapter 5 for more information on the indirection sequence. 


Figure 3-36: Absolute Direct Function Call 


_C_ 

extern 

void function(); 
function(); 

or: 


Assembly 


global 

function 

bsr 

function#plt 


global function 
bsr function 


Figure 3-36 shows two methods for effecting a call in absolute code. Note that 
the #plt suffix can be supplied or omitted. Supplying the #plt suffix is con¬ 
venient if it is desirable to make absolute and position-independent function calls 
in the same way. Omitting the #plt suffix is convenient if it is desirable to make 
absolute function calls the way they have been made traditionally. 

Supplying the #plt suffix does not necessarily result in the use of a procedure 
linkage table entry. If caller and callee are both in the executable file, for exam¬ 
ple, no PLT entry is needed. On the other hand, omitting the #plt suffix may 
result in the use of a PLT entry. If the link editor determines that the executable 
file is making reference to a function defined in a shared object, the link editor 
uses a PLT entry for the reference. 


LOW-LEVEL SYSTEM INFORMATION 


3-51 






Coding Examples 


Figure 3-37: Position-Independent Direct Function Call 


_C_ 

extern 

void function(); 
function(); 


Assembly 


global 

function 

bsr 

function#plt 


or: 


global 

function 

or .u 

#rl, #r0,#hil6(function#gotp_rel) 

or 

#rl,#rl,#lol6(function#gotp_rel) 

Id 

#rl,#r25,#rl 

jsr 

#rl 


Figure 3-37 shows two methods for effecting a call in position-independent code. 
If a bsr instruction is used, the #plt suffix should be supplied. Without the #plt 
suffix, a reference in a shared object to an external function resolves not to a PLT 
entry in the shared object, but to the canonical address for the function. (See 
"Function Addresses" in Chapter 5 for more information.) Such resolution 
compromises the position independence of the shared object. 

As the second alternative in Figure 3-37 shows, the indirection of the procedure 
linkage table entry may be avoided by making direct reference to the global offset 
table procedure entry for the function. The instruction sequence shown assumes 
that the addressing base is held in register #r25. 

Other sequences for effecting a direct function call are possible. For example, in 
absolute code, the global offset table procedure entry could be loaded directly 
and used with a jsr instruction. In position-independent code, the global offset 
table procedure entry can be loaded more concisely as long as there are not too 
many global offset table entries. 
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Figure 3-38: Absolute Indirect Function Call 

C Assembly 


extern void 

extern void 
ptr = name; 

(*ptr) (); 
name () ; 

(*ptr)(); 



global 

ptr, name 

or .u 

#r2,#r0,#hil6(name) 

or 

#r2,#r2,#lol6(name) 

or .u 

#r3,#r0,#hil6(ptr) 

St 

#r2,#r3,#lol6(ptr) 

or .u 

#rl,#r0,#hil6(ptr) 

Id 

#rl,#rl,#lol6(ptr) 

jsr 

#rl 


Figure 3-39: Position-Independent Indirect Function Call 

C Assembly 


global 

ptr, name 

or .u 

#r2,#r0,#hil6(name#got_rel) 

or 

#r2, #r2,#lol6(name#got rel) 

Id 

#r2,#r25,#r2 

or.u 

#r3,#r0,#hil6(ptr#got_rel) 

or 

#r3,#r3,#lol6(ptr#got_rel) 

Id 

#r3,#r25,#r3 

St 

#r2,#r3,0 

or.u 

#rl,#r0,#hil6(ptr#got_rel) 

or 

#rl,#rl,#lol6(ptr#got rel) 

Id 

#rl,#r25,#rl 

Id 

#rl,#rl,0 

jsr 

#rl 


extern void 

extern void 
ptr = name; 

(*ptr) (); 
name (); 

(*ptr)(); 
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Variable Argument List 

Previous sections describe the rules for passing arguments. Unfortunately, some 
otherwise portable C programs depend on the argument passing scheme, impli¬ 
citly assuming that 1) all arguments reside on the stack, and 2) arguments appear 
in increasing order on the stack. Programs that make these assumptions never 
have been portable, but they have worked on many machines. Portable C pro¬ 
grams should use the header files <stdarg.h> or <varargs .h> to deal with vari¬ 
able argument lists (on MC88100 and other machines as well). 


Allocating Stack Space Dynamically 


Figure 3-40: Dynamic Stack Space Allocation 

Before After 


frame pointer 
stack pointer 


fixed 

frame 

area 


argument 

area 


> 


(High Memory) —> 


fixed 

frame 

area 


frame pointer 


dynamic 

stack 

space 


argument 

area 


stack pointer —> 


direction of 
stack growth 


♦ 


<— (Low Memory) —> 


The M88000 architecture supports dynamic stack space allocation for those 
languages that require it. The mechanism for allocating dynamic space is embed¬ 
ded completely within a function and does not affect the standard calling 
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sequence. Thus, functions that need dynamic stack frame sizes can call functions 
that do not, and vice versa. 

A typical variant of the mechanism is described below and diagrammed in Fig¬ 
ure 3-40. The figure shows the layout of a stack frame before and after dynamic 
stack allocation. The fixed frame area is used for storage of function data, such as 
local variables, whose sizes are known to the compiler. The fixed frame area is 
allocated at function entry and does not change in size or position during the 
function's activation. The argument area is used for storage of arguments passed 
in calls to other functions. Its size is also known to the compiler and can be allo¬ 
cated along with the fixed frame area at function entry. However, the standard 
calling sequence requires that the stack pointer locate the argument area, so the 
argument area must move when dynamic stack allocation occurs. 

Data in the argument area are naturally addressed at constant offsets from the 
stack pointer. However, in the presence of dynamic stack allocation, the offsets 
from the stack pointer to the data in the fixed frame area are not constant. To 
provide addressability, a frame pointer is established to locate the fixed frame 
area consistently throughout the function's activation. 

Dynamic stack allocation is accomplished by "opening" the stack just above the 
argument area. The following steps show the process in detail. 

1. The amount of dynamic space to be allocated is rounded up to a multiple 
of 16 bytes, so that 16-byte stack alignment is maintained. 

2. The stack pointer is decreased by the rounded byte count. 

3. All active data in the argument area, if any, are copied from the previous 
position of the stack pointer to the new position. The amount of data to be 
copied is known to the compiler. 

4. The address of the newly allocated dynamic stack space is the sum of the 
new value of the stack pointer and the size of argument area. 

The above process can be repeated as many times as desired within a single func¬ 
tion activation. When it is time to return, the stack pointer is first reset to its posi¬ 
tion as shown in the left portion of Figure 3-40, thereby removing all dynamically 
allocated stack space. Normal return processing may then ensue. 
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Even in the presence of signals, dynamic allocation is "safe." If a signal inter¬ 
rupts allocation, one of three things can happen. 

1. The signal handler can return. The process then resumes the dynamic allo¬ 
cation from the point of interruption. 

2. The signal handler can execute a non-local goto, or long jmp [see 

set jmp(BAJLIB)]. This resets the process to a new context in a previous 
stack frame, automatically discarding the dynamic allocation. 

3. The process can terminate. 

Regardless of when the signal arrives during dynamic allocation, the result is a 
consistent (though possibly dead) process. 
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The M88000 ABI opts not to prescribe the form of a stack frame, in order to leave 
compilers with the greatest possible flexibility to generate efficient code. For 
example, no convention is defined to link stack frames at execution time, and a 
compiler may elect not to use a frame pointer for a particular routine. The lack of 
a traditional stack frame convention, however, would make low-level debugging 
impossible, were it not for the alternate convention described here. 

This section defines a mechanism by which programs describe relevant aspects of 
their text sections. The essence of the mechanism is that information about 
important execution-time characteristics of procedures is provided statically, by 
the compiler and link editor, rather than dynamically, by executing instructions 
at runtime, wherever possible. Information describing a procedure is generated 
by the compiler and is associated with the procedure by the link editor. When 
the information relevant to a particular text address is needed, the text address is 
mapped to the procedure containing the address, and the text description infor¬ 
mation associated with the procedure is consulted. 

Text description information describes code in an object file. This code is 
referred to as "text" because it usually resides in the .text section. However, 
code may reside in other sections with attributes similar to those of the .text 
section, and even in sections with attributes similar to those of the . data section, 
provided that the latter sections are made executable during execution. Refer¬ 
ences to "text" should be taken to mean references to "code" in its more general 
form. 


Tdesc Information 

A text chunk is a contiguous sequence of zero or more words of text of an object 
file. A text chunk consisting of zero words is an empty text chunk . The start 
address of a non-empty text chunk is the minimum of the addresses of the words 
of the non-empty text chunk. The end address of a non-empty text chunk is the 
maximum of the addresses of the words of the non-empty text chunk, plus 4. 
The start address and end address of an empty text chunk are equal. The start 
address is inclusive and the end address is exclusive. An address is said to be 
"in" a text chunk if it is greater than or equal to the start address of the text 
chunk and less than the end address of the text chunk. A word is said to be "in" 
a text chunk if its address is in the text chunk. 


LOW-LEVEL SYSTEM INFORMATION 


3-57 



Text Description Information 


Contributors of text (typically compilers and assemblers) shall partition that text 
into one or more text chunks. All text chunks so defined for an object file must 
not overlap; that is, no word may be in more than one text chunk. 

Contributors of text identify a text chunk and associate information descriptive of 
that text chunk by contributing a "tdesc chunk" to the . tdesc section. The 
.tdesc section is system-defined. It has the shf alloc attribute, it does not have 
the shfjwrite attribute, and it may or may not have the shf_execinstr attribute. 

A tdesc chunk begins on a word boundary and is a contiguous sequence of words 
with the following structure: 


Figure 3-41: Tdesc Chunk 


Word Bit T i . .. 

„ ~ Interpretation 

Position Range r 


0 

31-24 

zeroes 


23-2 

info length, in bytes 


1-0 

info alignment exponent 

1 

31-0 

info protocol 

2 

31-0 

start address of text chunk 

3 

31-0 

end address of text chunk 

4+ 


info 


The zeroes in word 0 are designed to be distinct from the high 8 bits of typical 
M88000 "no-op" instructions (instructions that, when executed, have no effect). 
This allows possible padding between tdesc chunks to be detected, whether the 
padding consists of words of zeroes or no-op instructions. 

The info protocol describes the form and interpretation of the tdesc chunk, pri¬ 
marily that of its info portion. 

The info protocol represents a contract between compiler and debugger/runtime 
system. Providing for different info protocols allows different (through space 
and time) compilers to use different strategies for describing their code. 
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The info length is the number of bytes of meaningful information that begin in 
word 4 of the structure. The tdesc chunk is padded with 0 to 3 bytes of 
undefined information to make its total size an integral multiple of 4 bytes. 

The info alignment exponent indicates the required alignment for the info field after 
the link editor has collected and reformatted the tdesc information (as described 
later). The info alignment exponent specifies the required alignment according to 
the following table: 


Figure 3-42: Info Field Alignment 


info alignment 
exponent 

alignment 
in bytes 

0 

1 

1 

2 

2 

4 

3 

8 


NOTE 


Alignments greater than 8 are not supported. 


Info Protocol 


Two info protocols are defined. They are identified with the integers 1 and 2. 

The only difference between the two protocols is the interpretation of the start 
address and end address of the text chunk. For protocol 1, the addresses are 
absolute; for protocol 2, the addresses are relative to the addressing base for the 
shared object containing the tdesc chunk. Hence, info protocol 2 can be used 
only in a shared object. Otherwise, the two info protocols are the same. For both 
protocols the info length is always 16 and the info alignment exponent is always 
2. The structure of the info for both protocols is as follows: 
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Figure 3-43: Info Structure 


Word Bit 
Position Range 


Interpretation 


0 

31-24 

info variant, the integer 1 


23-7 

register save mask, for registers #rl4-#r30; bit 7 is 
the #r30 save mask, bit 8 for #r29, etc., consecutively 
until bit 23 for #r 14 


6 

zero 


5 

return address info discriminant 


4-0 

frame address register 

1 

31-0 

frame address offset 

2 

31-0 

return address info 

3 

31-0 

register save offset 


The above structure is the only currently defined variant. Zeroes are required 
where no useful information is defined to facilitate future extension. 

The info field of the tdesc chunk describes important low-level characteristics of 
the execution environment which is in effect when the instruction pointer is in 
the associated text chunk. Because the information in the tdesc chunk is 
unchanging, it must depend on the context. The context consists of a text address 
and the values that the registers available to user-level programs would have 
were control about to proceed to the instruction addressed by the text address. 
The text address portion of a context is called its instruction pointer. 

The canonical frame address (abbreviated "CFA") for a procedure is the value of the 
stack pointer at entry to the procedure. The CFA shall be computable from the 
procedure's context and its text chunk's associated tdesc chunk's info field as fol¬ 
lows: 

CFA = contents_of( frame address register ) + frame address offset 

where "+" represents machine address arithmetic, and "contents_of(reg/sfer)" 
represents the value of the indicated register in the procedure's context. 
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Procedures that construct a "frame pointer" in a register will specify that register 
as the frame address register and the difference between the initial stack pointer 
value and the contents of that register as the frame address offset. Procedures 
that do not construct a frame pointer explicitly will specify the stack pointer as 
the frame address register and the (necessarily) fixed frame size as the frame 
address offset. 

The current size of a frame can be computed as follows: 
frame size = CFA - contents_of( #r31) 

where represents mathematical subtraction. (The stack pointer is always 
housed in #r31.) 

A frame position is a (byte) address relative to the CFA; that is, to calculate the 
address of a word at a frame position, sum (using machine address arithmetic) 
the CFA and the frame position. A frame position must be an integral multiple of 
4. That is, frame positions mark word-aligned positions in the frame. 

The return address for a procedure is the text address to which the procedure 
would return control were it to complete normally. Currently the return address 
must be "exact;" that is, a procedure is constrained to return exactly to the return 
address if it returns normally. The procedure housed in the text chunk that the 
return address of another procedure is in is known as the parent or caller of that 
other procedure. Note that, in the case of "tail call," the caller is not the pro¬ 
cedure that passed control directly, but rather an ancestor of that procedure. 

The return address shall be computable from the procedure's context and its text 
chunk's associated tdesc chunk's info field as follows: If the return address info 
discriminant is 0, the return address is the value of the register specified by the 
return address info field, with its low two bits cleared; if the return address info 
discriminant is 1, the return address is the value of the word at the frame position 
specified by the return address info field, with its low two bits cleared. A return 
address is always word-aligned. Ignoring the low two bits of return address 
values mimics the behavior of the hardware and allows other useful information 
to be stored there. 

The return address for a procedure is contained in #rl at entry to the procedure. 
A procedure that calls another procedure must store the initial contents of #rl in 
its frame. 


LOW-LEVEL SYSTEM INFORMATION 


3-61 



Text Description Information 


A leaf procedure (one that calls no other) may not need to store the contents of 
#rl, so its return address would remain there. However, a leaf procedure may 
need to free #rl, to use a bsr instruction which transfers within the procedure to 
locate the procedure in a position independent manner. In this case, the pro¬ 
cedure may save the initial contents of #rl in another register instead of in its 
frame. 

A return address value of zero indicates the absence of a parent text chunk and 
hence terminates a return address chain. The runtime initializer (typically crtO) 
shall have a return address, as described by its tdesc information, of zero. Stack 
traceback is achieved by following the chain of return addresses from callee to 
caller. A distinguished value for the end of this chain is required to make the 
traceback terminate. 

The register save mask may have "1" bits only in bit positions corresponding to 
preserved register numbers. The register save mask must have a "1" bit in any 
bit position corresponding to a preserved register that is modified by the pro¬ 
cedure. The values at procedure entry of the registers marked by "l" bits in the 
register save mask must be stored in the frame. The lowest-numbered register 
whose mask bit is "l" is stored at the frame position specified by the register 
save offset. Successively higher-numbered registers whose mask bits are "1" are 
stored in successive words in the frame at increasing addresses. A bit in the 
register save mask at position p, relative to the least significant bit of the mask, 
corresponds to the register numbered 30 -p. 

Both the tdesc chunk header and info field for info protocols 1 and 2 are 16 bytes 
in length. This avoids padding with assemblers that pad section sizes to multi¬ 
ples of 16 bytes. 

Typically, the execution environment of a procedure is not fully established until 
after several initial instructions have been executed. These initial instructions are 
often referred to as the procedure's prologue. Similarly, the procedure's execution 
environment is typically disestablished incrementally by final instructions 
referred to as the procedure's epilogue. That portion of a procedure which is nei¬ 
ther prologue nor epilogue is termed body. 

The simple information provided by a tdesc chunk with info protocols 1 and 2 
can describe only a single, unchanging execution environment. This suffices for a 
single tdesc chunk to describe a procedure's body. However, the procedure's 
prologue and epilogue portions are not correctly described by the same tdesc 
information. Hence, the text chunk that covers the procedure's body must not 
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also cover its prologue and epilogue sections. Additional text chunks can be 
defined to describe prologue and epilogue sections. However, because the exe¬ 
cution environment typically changes frequently during prologue and epilogue 
sections, possibly many additional, small text chunks, each with its own tdesc 
chunk, would be required. For this reason, the requirement as to which instruc¬ 
tions must be in a text chunk (and hence which must be described by tdesc infor¬ 
mation) is left purposely vague. Discretion is left to the implementation. 


Map Protocol 

The link editor treats tdesc information specially. When producing an executable 
file or shared object file, it reformats the contributions to the .tdesc section 
before making them part of a segment of the object file. The reformatted tdesc 
information may consist of one or more pieces. Each piece of tdesc information 
is aligned to a word boundary and has the following general structure: 


Figure 3-44: Tdesc Information Piece 


Word Bit 
Position Range 


Interpretation 


0 

31-0 

map protocol 

1+ 


info 


The map protocol describes the form and interpretation of the info portion of the 
tdesc information piece. 

The map protocol represents a contract between link editor and 
debugger/runtime system. Providing for different map protocols allows dif¬ 
ferent (through space and time) link editors to use different strategies for map¬ 
ping text addresses to tdesc chunks. 
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Two map protocols are defined. They are identified with the integers 1 and 2. 
The structure of the info for map protocol 1 is shown in Figure 3-45. 


Figure 3-45: Map Protocol 1 


Word 

Position 

Bit 

Range 

Interpretation 

0 

1 + 

31-0 

end address of this structure 
tdesc chunk sequence 


The first word of info gives the address just beyond the end of this piece of tdesc 
information. Beginning at the second word is a concatenation of all contributions 
to the .tdesc section, in arbitrary order. This concatenation includes all tdesc 
chunks and may include padding words before, between, and after tdesc chunks. 
A padding word is either a word all of whose bits are zero, or a word whose high 
8 bits are not all zero. The required alignment of the info fields of the tdesc 
chunks shall be met. Hence, the only required "reformatting" performed for 
map protocol 1 is the addition of the map protocol word and the end address 
word. This map protocol is crude, but it is adequate to support debugging, 
because debugging performance is not critical. 

The structure of the info for map protocol 2 is shown in Figure 3-46. 


Figure 3-46: Map Protocol 2 


Word 

Position 

Bit 

Range 

Interpretation 

0 

1+ 

31-0 

end address of this structure 
array of tdesc piece entries 
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The first word of info gives the address just beyond the end of this piece of tdesc 
information. The remainder of the piece is an array of structures with the follow¬ 
ing form: 


Figure 3-47: Tdesc Piece Entry 


Word 

Position 

Bit 

Range 

Interpretation 

0 

1 

31-0 

31-0 

address of tdesc information piece 
addressing base for piece 


The first word gives the address of another piece of tdesc information. An 
address of zero represents an absent piece. If the first word is nonzero, the 
second word gives the addressing base for any immediately subordinate tdesc 
chunks with info protocol 2. 

Together, map protocols 1 and 2 provide the capability to represent a tree of 
tdesc information. Map protocol 1 pieces serve as the leaves of the tree; map pro¬ 
tocol 2 pieces serve as the nodes of the tree. 

When producing an executable file or shared object file, the link editor reformats 
the contributions to the .tdesc section into a single piece with map protocol 1. 
This tdesc information piece resides in a segment with read permission but 
without write permission. 

When producing an executable file that does not participate in dynamic linking, 
the link editor defines the symbol tdesc as the address of the tdesc information 
piece with map protocol 1. 

When producing an object file that participates in dynamic linking, the link editor 
includes a dynamic linking array entry with d tag member equal to 
dt_88k_tdesc and d_ptr member equal to the address of the object file's tdesc 
information piece with map protocol 1. Additionally, in an executable file that 
participates in dynamic linking, the link editor allocates a tdesc information piece 
with map protocol 2 and defines the symbol _tdesc as the address of this second 
piece. This second piece resides in a segment with both read and write permis¬ 
sions and has at least as many tdesc piece entries as two more than the number of 
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shared object files referenced by the executable file. Both words of each of the 
entries are initially zero. The dynamic linker fills in an entry for each object file 
whose dynamic linking array it processes. 


Debug Info 

When producing an executable file, the link editor creates the following data 
structure in a segment with read permission but without write permission and 
defines the symbol _debug__inf o as the address of the beginning of the structure. 
(See "Program Header" in Chapter 5 for the segment description.) The structure 
shall be word-aligned. 


Figure 3-48: debug info Structure 


Word 

Position 

Bit 

Range 

Interpretation 

0 

31-0 

debug info protocol, the integer 1 

1 

31-0 

the value of the tdesc symbol 

2 

31-0 

number of text words 

3 

31-0 

pointer to text words 

4 

31-0 

number of data words 

5 

31-0 

pointer to data words 


The pointer to text words is the address of a contiguous sequence of words that 
reside in a segment with execute permission and that are not otherwise refer¬ 
enced. The number of text words indicates the number of such words. The 
number of text words shall be at least 1. These words are available to a 
debugger, for use as places to set breakpoints safely for its own use. 

The pointer to data words is the address of a contiguous sequence of words that 
reside in a segment with write permission and that are not otherwise referenced. 
The number of data words indicates the number of such words. The number of 
data words shall be at least 256. These words are available to a debugger, for use 
as places to store data safely for its own use in the memory of the process being 
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debugged. 

When producing an executable file, the link editor shall create a single segment of 
type pt_88k_debinfaddr. This segment shall contain a single word, whose value 
is the value of the debug inf o symbol. 
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ELF Header 


Machine Information 


For file identification in e__ident, the M88000 requires the following values. 


Figure 4-1: M88000 Identification, e ident 

Position Value 

e_ident [EI_CLASS] ELFCLASS32 

evident [ei_data] elfdata2msb 


The ELF header's e_f lags member holds bit flags associated with the file. The 
M88000 defines no flags, so this member contains zero. Processor identification 
resides in the ELF header's e_machine member and must have the value 5, 
defined as the name em 88K. 
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The M88000 architecture is such that an individual section cannot permit writing 
and execution attributes— shf write and shf execinstr —at the same time. 


Special Sections 

Various sections hold program and control information. Sections in the list 
below are used by the system and have the indicated types and attributes. 


Figure 4-2: Special Sections 


Name 

Type 

Attributes 

.got 

SHTJPROGBITS 

SHF ALLOC + SHF WRITE 

.pit 

SHT_PROGBITS 

SHF_ALLOC + SHFJEXECINSTR 

.tdesc 

SHT_PROGBITS 

see below 


.tdesc This section holds text description information. It has the 

shf_alloc attribute, it does not have the shf write attribute, and it 
may or may not have the shf_execinstr attribute. See 'Text 
Description Information" in Chapter 3 for more information. 
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Symbol Values 

If an executable file contains a reference to a function defined in one of its associ¬ 
ated shared objects, the symbol table section for that file will contain an entry for 
that symbol. The st_shndx member of that symbol table entry contains 
shn undef. This signals to the dynamic linker that the symbol definition for that 
function is not contained in the executable file itself. If that symbol has been allo¬ 
cated a procedure linkage table entry in the executable file, and the st_value 
member for that symbol table entry is non-zero, the value will contain the virtual 
address of the first instruction of that procedure linkage table entry. Otherwise, 
the st_value member contains zero. This procedure linkage table entry address 
is used by the dynamic linker in resolving references to the address of the func¬ 
tion. See "Function Addresses" in Chapter 5 for details. 
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Relocation Types 

Relocation entries describe how to alter the following instruction and data fields 
(bit numbers appear in the lower box corners; byte numbers appear in the upper 
box corners). 

Figure 4-3: Relocatable Fields 



byte8 This specifies an 8-bit field occupying 1 byte with arbitrary alignment. 

halfl6 This specifies a 16-bit field occupying 2 bytes with 2-byte alignment. 
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0 

i 

0x0102 

01 

02 


word32 This specifies a 32-bit field occupying 4 bytes with 4-byte alignment. 
These values use the byte order illustrated below. 

uawd32 This specifies a 32-bit field occupying 4 bytes with arbitrary align¬ 
ment. These values use the same byte order as for word32 . 



0 

i 

2 

3 

0x01020304 

01 

02 

03 

04 


lozvl6 This specifies a 16-bit field occupying the least significant bits of a 

field similar to word32 . These bits represent values in the same byte 
order as word32 . 

low26 This specifies a 26-bit field occupying the least significant bits of a 

field similar to word32 . These bits represent values in the same byte 
order as word32 . 

Calculations below assume the actions are transforming a relocatable file into 
either an executable or a shared object file. Conceptually, the link editor merges 
one or more relocatable files to form the output. It first decides how to combine 
and locate the input files, then updates the symbol values, and finally performs 
the relocation. Relocations applied to executable or shared object files are similar 
and accomplish the same result. Descriptions below use the following notation. 

A This means the addend used to compute the value of the relocatable 

field. 

ab This means the addressing base for the shared object. See Chapter 5 

for more information. 

B This means the base address at which a shared object has been loaded 

into memory during execution. Generally, a shared object file is built 
with a 0 base virtual address, but the execution address will be dif¬ 
ferent. See "Program Header" in the System V ABI for more 
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information about the base address. 

G This means the place (section offset or address) of a global offset table 

entry for the symbol. See Chapter 5 for more information. 

GP This means the place (section offset or address) of a global offset table 

procedure entry for the symbol. See Chapter 5 for more information. 

L This means the place (section offset or address) of the symbol, or of a 

procedure linkage table entry for the symbol. See Chapter 5 for more 
information. 

P This means the place (section offset or address) of the storage unit 

being relocated (computed using r_of fset). 

S This means the value of the symbol whose index resides in the reloca¬ 

tion entry. 

Relocation entries apply to bytes ( byte8 ), halfwords {halfl6) f or words (the oth¬ 
ers). In any case, the r_of f set value designates the offset or virtual address of 
the first byte of the affected storage unit. The relocation type specifies which bits 
to change and how to calculate their values. The M88000 uses only Elf 32_Rela 
relocation entries, with explicit addends. Thus the r_addend member serves as 
the relocation addend. 

The following general rules apply to the interpretation of the relocation types in 
Figure 4-4. 

■ "+" and denote 32-bit modulus addition and subtraction, respectively. 
"»" denotes arithmetic right shifting of the value of the left operand by the 
number of bits given by the right operand. 

■ For relocation types whose names end in "_disp16", the upper 15 bits of the 
value computed before shifting must all be the same. For relocation types 
whose names end in // _disp26", the upper 5 bits of the value computed 
before shifting must all be the same. For relocation types whose names end 
in either "_disp16" or /< _disp26", the low 2 bits of the value computed 
before shifting must all be zero. 

■ For relocation types whose names end in "_8", the upper 24 bits of the com¬ 
puted value must all be zero. For relocation types whose names end in 
"_8S", the upper 25 bits of the computed value must all be the same. For 
relocation types whose names end in "_16", the upper 16 bits of the com¬ 
puted value must all be zero. For relocation types whose names end in 
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"_16S", the upper 17 bits of the computed value must all be the same. 

■ #hil6 (value) and #lol6 (value) denote the high and low 16 bits, respec¬ 
tively, of the indicated value. 

■ Reference in a calculation to the value "G" implicitly creates a global offset 
table entry for the indicated symbol. Reference in a calculation to the value 
"gp" implicitly creates a global offset table procedure entry for the indicated 
symbol. Reference in a calculation to the value "L" may implicitly create a 
procedure linkage table entry for the indicated symbol. 

■ A relocation type whose calculation involves either the value "B" or the 
value "ab" may only be used in a shared object. 

■ For relocation types whose names begin with either ' 'r_8 8 k_abd i ff_' ' or 

' 'r_8 8 k_abrel_' ', the symbol's value must represent an address in the shared 
object containing the relocation. 

■ For relocation types whose names include "_srel_", the address of the 
storage unit affected by the relocation either must both be in the same shared 
object, or must both be in an executable file. 

■ Where a relocation type does not use the associated symbol, the symbol 
index in the relocation entry must be zero. 

■ The link editor shall detect and report violations of restrictions described 
above. 
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Figure 4-4: Relocation Types, Part 1 of 2 


Name 

Value 

Field 

Calculation 

r 88k none 

0 

none 

none 

r 88k COPY 

1 

none 

see below 

R 88k GOTP ENT 

2 

word32 

see below 

r_88k_8 

4 

byte8 

S + A 

R 88k 8S 

5 

byte8 

S + A 

r_88kJL6S 

7 

halfl6 

S + A 

R 88k DISP16 

8 

halfl6 

(S + A - P) » 2 

R 88k DISP26 

10 

low26 

(S + A - P) » 2 

R 88K PLT DISP26 

14 

low26 

(L + A - P) » 2 

R 88k bbased 32 

16 

word32 

B + A 

r 88k bbased 32ua 

17 

uawd32 

B + A 

R 88K BBASED 16H 

18 

halfl6 

#hil6 ( B + A ) 

R 88k bbased 16L 

19 

half 16 

#lol6( B + A ) 

R 88k abdiff 32 

24 

word32 

AB - S + A 

r 88k abdiff 32ua 

25 

uawd32 

AB - S + A 

r_88k_a bdi ff_ 1 6H 

26 

halfl6 

#hil6( AB - S + A ) 

R_8 8 K_ABD 1 FF_16L 

27 

halfl6 

#lol6( AB - S + A ) 

r_88k_abdiff_16 

28 

halfl6 

AB - S + A 

r_88k_32 

32 

zvord.32 

S + A 

r_88k_32ua 

33 

uawd32 

S + A 

r_88k_16H 

34 

halfl6 

#hil6( S + A ) 

r_88k_16L 

35 

half 16 

#lol6( S + A ) 

R_88k_16 

36 

halfl6 

S + A 

R_88k_GOT_32 

40 

word32 

G + A 

r_8 8k_g° t _32ua 

41 

uawd32 

G + A 

r_88k_g°t_16H 

42 

half 16 

#hil6 ( G + A ) 

r_8 8k_g° t _1 6 Ij 

43 

half 16 

#lol6 ( G + A ) 

r_88k_got_16 

44 

half!6 

G + A 

r_88k_gotp_32 

48 

zvord32 

GP + A 

r_88k_g°tp_32ua 

49 

uawd32 

GP + A 

r_8 8k_ g ° t p_16H 

50 

halfl6 

#hil6 ( GP + A ) 

R_88k_ g ° t p_16L 

51 

halfl6 

#lol6 ( GP + A ) 

r_88k_ g ° tp _16 

52 

half 16 

GP + A 
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Figure 4-5: Relocation Types, Part 2 of 2 


Name 

Value 

Field 

Calculation 

R 88K plt 32 

56 

zvord32 

L + A 

R 88k plt 32ua 

57 

uawd32 

L + A 

r 88k PLT 16H 

58 

halfl6 

foil6 ( L + A ) 

r 88k plt 16L 

59 

half 16 

#lol6( L + A ) 

R 88k plt 16 

60 

half 16 

L + A 

r 88k abrel 32 

64 

word32 

S + A - AB 

R 88k abrel 32ua 

65 

uawd32 

S + A - AB 

R 88k ABREL 16H 

66 

half 16 

#hil6( S + A - AB ) 

R 88k abrel 16L 

67 

half 16 

#lol6( S + A - AB ) 

R 88k abrel 16 

68 

halfl6 

S + A - AB 

R 88k GOT ABREL 32 

72 

word32 

G + A - AB 

r 88k got abrel 32ua 

73 

uawd32 

G + A - AB 

r 88k got abrel 16H 

74 

half 16 

#hil6( G + A - AB ) 

r_8 8 k_got_abrel_1 6L 

75 

halfl6 

#lol6( G + A - AB ) 

R 8 8K GOT ABREL 16 

76 

halfl6 

G + A - AB 

R_88K_GOTP_ABREL_32 

80 

word32 

GP + A - AB 

r_8 8k_gotp_abrel_32ua 

81 

uawd32 

GP + A - AB 

r_8 8k_gotp_abrel_16h 

82 

halfl6 

#hil6 ( GP + A - AB ) 

r 88k gotp_abrel_16L 

83 

halfl6 

#lol6( GP + A - AB ) 

r_8 8k_gotp_abrel_1 6 

84 

halfl6 

GP + A - AB 

r_88k_pl t _abrel_32 

88 

word32 

L + A - AB 

r_8 8k_plt_abrel_32ua 

89 

uawd32 

L + A - AB 

r88k_plt_abrel_16H 

90 

halfl6 

#hil6( L + A - AB ) 

r88k_plt_abrel_16L 

91 

halfl6 

#lol6( L + A - AB ) 

r_8 8k_plt_abrel_16 

92 

halfl6 

L + A - AB 

r_88k_ s rel_32 

96 

word32 

S + A - P 

r_88k_srel_32ua 

97 

uawd32 

S + A - P 

r_8 8k_srel_16H 

98 

halfl6 

#hil6( S + A - P ) 

r_8 8k_srel_16L 

99 

halfl6 

#lol6( S + A - P ) 
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Relocation types with special semantics are described below. 

R _88K_co pY This relocation type assists dynamic linking. Its offset 

member refers to a location in a writable segment. The 
symbol table index specifies a symbol that should exist 
both in the current object file and in a shared object. 
During execution, the dynamic linker copies data associ¬ 
ated with the shared object's symbol to the location 
specified by the offset. 

r_88k_g° tp _en t This relocation type assists dynamic linking. The reloca¬ 

tion offset gives the location of a global offset table pro¬ 
cedure entry. The relocation symbol names the pro¬ 
cedure. The relocation addend gives the address of the 
associated GOTP binding entry. For an executable file, 
this address is absolute; for a shared object file, it is rela¬ 
tive to the base address for the shared object. See 
Chapter 5 for details. 

The use of relocation types whose names end in "_16" is generally subject to 
failure, because the value computed may not fit in 16 bits. However, the use of 
the r_88k_got_abrel_16 and r_88k_got p _abrel_16 relocation types shall not fail 
unless the total number of distinct GOT and GOTP entries for the executable or 
shared object being link edited exceeds 16 380. In other words, the link editor is 
obliged to favor GOT and GOTP entries when choosing an addressing base and 
laying out the private data of either the executable or shared object file. 
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Program Header 


An additional segment type, pt_88k_debinfaddr, is defined with value 
0x7000 0001. This segment contains a single word whose value is the value of the 
_debug_inf o symbol. The segment is created by the link editor. It allows a 
debugger operating as a process separate from the process it is debugging to 
locate the debug information in the executable file. 
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The M88000 architecture is such that an individual segment cannot permit writ¬ 
ing and execution attributes— pf_w and pf_x —at the same time. The following 
combinations of segment permissions are valid for the M88000: 


Figure 5-1: Segment Permissions 


Flags 

Value 

Permissions Granted 

Read 

Write 

Execute 

none 

0 

no 

no 

no 

PF_X 

1 

unspecified 

no 

yes 

PF W 

2 

unspecified 

yes 

unspecified 

PF_R 

4 

yes 

no 

unspecified 

PF_R + PF_X 

5 

yes 

no 

yes 

PF_R+PF_W 

6 

yes 

yes 

unspecified 


In the table, "yes" indicates the access shall be allowed; "no" indicates the access 
shall be denied and a sigbus signal shall be sent to the process; "unspecified" 
indicates that the process cannot rely on either obtaining access nor receiving the 
signal. 

For the M88000 architecture, the segment permissions indicate only the initial 
state of the segment. The use of the mprotect (KE_OS) function can change the 
state during execution. 
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As the system creates or augments a process image, it logically copies a file's seg¬ 
ment to a virtual memory segment. When—and if—the system physically reads 
the file depends on the program's execution behavior, system load, etc. A pro¬ 
cess does not require a physical page unless it references the logical page during 
execution, and processes commonly leave many pages unreferenced. Therefore 
delaying physical reads frequently obviates them, improving system perfor¬ 
mance. To obtain this efficiency in practice, executable and shared object files 
must have segment images whose file offsets and virtual addresses are 
congruent, modulo the page size. 

Virtual addresses and file offsets for M88000 segments are congruent modulo 
64K (0x10000). The value of the p_align member of each program header in a 
shared object file must be 64K. 


Figure 5-2: Executable File Example 

File Offset File Virtual Address 


0x10100 

0x3beff 

0x4bf00 

0x50cff 


0x100 


0x2bf00 


0x30d00 


ELF header 


Program header table 


Other information 


Text segment 
0x2be00 bytes 


Data segment 
0x4e00 bytes 


Other information 
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Figure 5-3: Program Header Segments Example 


Member 

Text 

Data 

p_type 

pt 88k load 

PT 88K LOAD 

p_offset 

0x100 

0x2bf00 

p vaddr 

0x10100 

0x4bf00 

pjpaddr 

unspecified 

unspecified 

p filesz 

0x2be00 

0x4e00 

p_memsz 

Ox2beOO 

0x5e24 

p flags 

PF_R + PF_X 

PF_R + PF_W 

p align 

0x10000 

0x10000 


Although the example's file offsets and virtual addresses are congruent modulo 
64 K for both text and data, up to four file pages hold impure text or data 
(depending on page size and file system block size). 

■ The first text page contains the ELF header, the program header table, and 
other information. 

■ The last text page holds a copy of the beginning of data. 

■ The first data page has a copy of the end of text. 

■ The last data page may contain file information not relevant to the running 
process. 

Logically, the system enforces the memory permissions as if each segment were 
complete and separate; segments' addresses are adjusted to ensure each logical 
page in the address space has a single set of permissions. In the example above, 
the region of the file holding the end of text and the beginning of data will be 
mapped twice: at one virtual address for text and at a different virtual address 
for data. 

The end of the data segment requires special handling for uninitialized data, 
which the system defines to begin with zero values. Thus if a file's last data page 
includes information not in the logical memory page, the extraneous data must 
be set to zero, not the unknown contents of the executable file. "Impurities" in 
the other three pages are not logically part of the process image; whether the 
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system expunges them is unspecified. The memory image for this program fol¬ 
lows, assuming 4 KB (0x1000) pages. 


Figure 5-4: Process Image Segments 


Virtual Address 
0x10000 

0x10100 


0x3bf00 


Contents 
Header padding 
0x100 bytes 
Text segment 


0x2be00 bytes 
Data padding 
0x100 bytes 


Segment 


Text 


0x4b000 

0x4bf00 


OxSOdOO 

0x51d24 


Text padding 
Oxf 00 bytes 
Data segment 


0x4e00 bytes 
Uninitialized data 
0x1024 zero bytes 
Page padding 
0x2dc zero bytes 


Data 


One aspect of segment loading differs between executable files and shared 
objects. Executable file segments typically contain absolute code [see "Coding 
Examples" in Chapter 3]. To let the process execute correctly, the segments must 
reside at the virtual addresses used to build the executable file. Thus the system 
uses the p_vaddr values unchanged as virtual addresses. 
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On the other hand, shared object segments typically contain position- 
independent code. This lets a segment's virtual address change from one process 
to another, without invalidating execution behavior. Though the system chooses 
virtual addresses for individual processes, it maintains the segments' relative posi¬ 
tions. Because position-independent code uses relative addressing between seg¬ 
ments, the difference between virtual addresses in memory must match the 
difference between virtual addresses in the file. The following table shows possi¬ 
ble shared object virtual address assignments for several processes, illustrating 
constant relative positioning. The table also illustrates the base address computa¬ 
tions. 


Figure 5-5: Example Shared Object Segment Addresses 


Source 

Text 

Data 

Base Address 

File 

0x200 

0x2a400 

0x0 

Process 1 

0xc0000200 

0xc002a400 

OxcOOOOOOO 

Process 2 

0xc0010200 

0xc003a400 

OxcOOlOOOO 

Process 3 

0xd0020200 

0xd004a400 

0xd0020000 

Process 4 

0xd0030200 

0xd005a400 

0xd0030000 
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Dynamic Section 

Dynamic section entries give information to the dynamic linker. Some of this 
information is processor-specific, including the interpretation of some entries in 
the dynamic structure. 

dt_pltgot This entry's d_ptr member gives the address of three consecu¬ 
tive words in the private data of an executable or shared object 
file. These 12 bytes must be 4-byte aligned. The first word must 
be set by the link editor to contain the address of the symbol 
_dynamic ; the address is absolute for an executable file and rela¬ 
tive to the base address for a shared object. The second and 
third words are used to support lazy binding. The dt_pltgot 
entry is required in every object file that participates in dynamic 
linking. The link editor chooses where to locate the three words; 
one natural place would be the beginning of the global offset 
table. 

DT_JMPREL 

DT_PLTRELSZ 

dt_pltrel On the M88000, these entries specify a relocation table that per¬ 
tains to global offset table procedure entries, rather than to the 
procedure linkage table, as described in the System V ABI. This 
relocation table should contain all relocation entries of type 
r _88k_gotp_ent, and only those entries. In particular, reloca¬ 
tion entries applying to the procedure linkage table are found 
with all other relocation entries in the relocation table specified 
by the dt_rela, dt_relasz, and dt_relaent entries. 
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The following additional dynamic array tags are defined: 


Figure 5-6: Dynamic Array Tags, d tag 


Name 

Value 

d_un 

Executable 

Shared Object 

dt_8 8k_addrbase 

0x70000001 

d_ptr 

ignored 

required 

dt_8 8k_pltstart 

0x70000002 

d_ptr 

optional 

optional 

dt_88k_pltend 

0x70000003 

d_ptr 

optional 

optional 

dt_88k_tdesc 

0x70000004 

d_ptr 

optional 

optional 


dt_8 8k_addrbase 

This entry's d ptr member gives the addressing base for the 
shared object. 

dt_88k_pltstart 

This entry's d ptr member gives the low address (inclusive) of 
the PLT region in an object file. 

dt_88k_pltend 

This entry's d ptr member gives the high address (exclusive) of 
the PLT region in an object file. 

dt_88k_tdesc This entry's d_ptr member gives the address of the tdesc infor¬ 
mation for the object file. See "Text Description Information" in 
Chapter 3 for more information. 

If either of dt_88k_pltstart or dt_88k_pltend is present, both must be present. 

The PLT region is that portion of an object file that must be made executable by 
the dynamic linker after relocations are performed in the region. The PLT region 
includes all PLT entries for the object file that require relocation by the dynamic 
linker. The region of memory between (((dt_88k_pltstart value) / 64K) * 64K) 
(inclusive) and ((((dt_88k_pltend value) + 64K - 1) / 64K) * 64K) (exclusive), 
where arithmetic is as for unsigned integers in the C language, is subject to being 
made executable by the dynamic linker. 
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Global Offset Table 


Position-independent code cannot, in general, contain absolute virtual addresses. 
Global offset tables hold absolute addresses in private data, thus making the 
addresses available without compromising the position-independence and shara- 
bility of a program's text. A program can reference its global offset table in 
several ways: 

■ An executable file can reference its global offset table absolutely, as it would 
any data, because the address of the global offset table is known to the link 
editor. A shared object can reference its global offset table with position- 
independent references, because all of the text and data of a shared object file 
remains fixed relative to itself no matter where the shared object segments 
are assigned in memory. 

■ A shared object typically references its global offset table relative to the 
shared object's addressing base. The link editor establishes the addressing 
base and the location of the global offset table, so it can calculate constant 
offsets to global offset table entries. The addressing base value can be com¬ 
puted by a function in a shared object in a position-independent manner as 
shown in Figure 3-32. 

■ References from a shared object's procedure linkage table to the global offset 
table procedure entries are made absolutely. This is possible because the 
procedure linkage table is private to the shared object. 

Initially, the global offset table holds information as required by its relocation 
entries (see "Relocation" in Chapter 4). When the dynamic linker creates 
memory segments for a loadable object file, it processes the relocation entries, 
some of which will refer to the global offset table. The dynamic linker deter¬ 
mines the associated symbol values, calculates their absolute addresses, and sets 
the global offset table entries to the proper values. Although the absolute 
addresses are unknown when the link editor builds an object file, the dynamic 
linker knows the addresses of all memory segments and can thus calculate the 
absolute addresses of the symbols contained therein. 

A global offset table entry provides direct access to the absolute address of a 
symbol, without compromising position independence and sharability. Because 
the executable file and shared objects have separate global offset tables, a symbol 
may appear in several tables. The dynamic linker processes all the global offset 
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table relocations before giving control to any code in the process image, thus 
ensuring the absolute addresses are available during execution. 

The dynamic linker may choose different memory segment addresses for the 
same shared object in different programs; it may even choose different library 
addresses for different executions of the same program. Nonetheless, memory 
segments do not change addresses once the process image is established. As long 
as a process exists, its memory segments reside at fixed virtual addresses. 

Global offset table ("GOT") entries are created by the link editor in response to 
the use of certain relocation types. A GOT entry is 4 bytes long and 4-byte 
aligned and is allocated in writable memory private to the executable or shared 
object file. After relocation by the link editor, the dynamic linker, or both, a GOT 
entry generally contains the value of its associated symbol, which is usually the 
address of the entity (object or function) represented by the symbol. The one 
exception is the case of a function for which there is a PLT entry in the executable 
file. In this case the GOT entry contains the address of that PLT entry. In this 
way, the address by which the executable file knows the function (its PLT entry 
address) is also the address by which all shared objects know the function. 

More efficient access to functions is provided by special GOT entries known as 
"global offset table procedure" ("GOTP") entries. Like GOT entries, GOTP entries 
are created by the link editor in response to use of certain relocation types, are 4 
bytes long and 4-byte aligned, are allocated in writable memory private to the 
executable or shared object file, and are relocated by the link editor, dynamic 
linker, or both. A GOTP entry, however, may only refer to a function. During 
execution, the GOTP entry contains an address to which control can be 
transferred in order to reach the function represented by the symbol associated 
with the GOTP entry. Moreover, the contents of the GOTP entry may change dur¬ 
ing execution. This is "lazy binding", described below. Although the contents of 
a GOTP entry may change during execution, every value contained in a GOTP 
entry serves to transfer control correctly to the associated function. 

A GOTP entry has an associated relocation of type r_88k_gotp_ent. The reloca¬ 
tion information and the initial contents of the entry are described under the 
R_8 8k_gotp_ent relocation type. 

There are two separate relocation operations that the dynamic linker may per¬ 
form for a GOTP entry. The first, called "pre-binding," is performed during the 
dynamic linker's relocation phase when lazy binding is in effect (when the 
ld bind now environment variable is missing or null). In pre-binding, the 
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dynamic linker rewrites the GOTP entry so that calling through it invokes the 
dynamic linker. When the first invocation is made through the GOTP entry, the 
dynamic linker gains control and performs the second relocation operation on 
the GOTP entry, called "binding." Binding involves locating the relocation table 
entry associated with the GOTP entry, looking up the associated symbol to find 
where the function resides in memory, rewriting the GOTP entry to point directly 
to the function, and finally transferring control to the function. If lazy binding is 
not in effect (the value of the ld_bind_now environment variable is non-null), the 
dynamic linker simply performs the binding operation during its relocation 
phase, bypassing the pre-binding step altogether. 


NOTE 


Lazy binding generally improves overall application performance, because 
unused symbols incur lower dynamic linking cost. Nevertheless, two situa¬ 
tions make lazy binding undesirable for some applications. First, the initial 
reference to a shared object function takes longer than subsequent calls, 
because the dynamic linker intercepts the call to resolve the symbol. Some 
applications cannot tolerate this unpredictability. Second, if an error occurs 
and the dynamic linker cannot resolve the symbol, the dynamic linker will ter¬ 
minate the program. Under lazy binding, this might occur at arbitrary times. 
Once again, some applications cannot tolerate this unpredictability. By turn¬ 
ing off lazy binding, the dynamic linker forces the failure to occur during pro¬ 
cess initialization, before the application receives control. 


The link editor and dynamic linker collaborate to support lazy binding. For each 
GOTP entry, the link editor creates a "GOTP binding" entry, a sequence of 
instructions that serves to transfer control to the dynamic linker. When lazy 
binding is in effect, the dynamic linker stores the address of the GOTP binding 
entry in the GOTP entry. (The addend in the relocation entry for the GOTP entry 
locates the GOTP binding entry.) The dynamic linker also stores a word identify¬ 
ing the executable or shared object file and the address of its binding routine in 
the second and third words, respectively, of the three words located by the 
dt_pltgot value for the executable or shared object file. 

The GOTP binding entry is responsible for transferring control to the address con¬ 
tained in the word at "dt pltgot value" + 8, having extended the stack by 16 
bytes with the following values: 
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Figure 5-7: GOTP Binding Entry Stack Frame 


#r31 Offset Contents 


12 

#rl value at time of call 

8 

reloc off value 

4 

word at "dt_pltgot value" + 4 

0 

the value 0 


The reloc_of f value is the offset, in bytes, from the dt jmprel value for the exe¬ 
cutable or shared object file containing the GOTP entry, to the relocation entry for 
the GOTP entry. 

The GOTP binding entry may destroy the contents of register #rll. The GOTP 
binding entry, in transferring to the dynamic linker, must place an appropriate 
return address in #rl, to maintain a proper return address chain for text descrip¬ 
tion information purposes. 

There are many ways for the link editor to satisfy the above requirements. One 
possible implementation of the GOTP binding entry is: 


Figure 5-8: GOTP Binding Entry 


or.u 

#rll, #r0,#hil6(reloc_off) 

or 

#rll, #rll,#lol6(reloc_off) 

br 

GOTP_binding helper 


where GOTP_binding_helper is a sequence of instructions particular to the given 
executable or shared object file. A GOTP binding helper routine that cooperates 
with GOTP binding entries as shown above could be: 
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Figure 5-9: GOTP Binding Helper 


subu 

#r31,#r31,16 

St 

#rl,#r31,12 

st 

#rll,#r31,8 

bsr 

here 

here: or. u 

#rll, #r0, #hil6 (DT_PLTGOT-here) 

or 

#rll, #rll, #lol6 (DT_PLTGOT-here) 

addu 

#rll,#rll,#rl 

Id 

#rl,#rll, 4 

st 

#rl,#r31, 4 

Id 

#rll,#rll,8 

st 

#r0,#r31,0 

jsr 

#rll 

or 

#r0,#r0,#r0 


The expression "dt pltgot— here" represents the distance from label here to the 
dt_pltgot -specified value. The final "no-op" instruction is needed so that the 
return address placed in #rl by the jsr instruction will correctly locate the GOTP 
binding helper routine for text description information purposes. 

The example sequences shown for the GOTP binding entry and GOTP binding 
helper routine are designed not to require any relocation by the dynamic linker. 
Hence, they can be part of the normal text of a shared object. In particular, they 
don't need to reside along with PLT entries in the PLT region. However, it may be 
convenient for the link editor to create a procedure linkage table consisting of the 
GOTP binding helper routine followed by PLT and GOTP binding entries for each 
GOTP entry. 
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Function Addresses 

References to the address of a function from an executable file and the shared 
objects associated with it might not resolve to the same value. References from 
within shared objects will normally be resolved by the dynamic linker to the vir¬ 
tual address of the function itself. References from within the executable file to a 
function defined in a shared object will normally be resolved by the link editor to 
the address of the procedure linkage table entry for that function within the exe¬ 
cutable file. 

To allow comparisons of function addresses to work as expected, if an executable 
file references a function defined in a shared object, the link editor will place the 
address of the procedure linkage table entry for that function in its associated 
symbol table entry. (See "Symbol Values" in Chapter 4.) The dynamic linker 
treats such symbol table entries specially. If the dynamic linker is searching for a 
symbol, and encounters a symbol table entry for that symbol in the executable 
file, it normally follows the rules below. 

■ If the st_shndx member of the symbol table entry is not shn undef, the 
dynamic linker has found a definition for the symbol and uses its st_value 
member as the symbol's address. 

■ If the st_shndx member is shn undef and the symbol is of type stt func 
and the st value member is not zero, the dynamic linker recognizes this 
entry as special and uses the st_value member as the symbol's address. 

■ Otherwise, the dynamic linker considers the symbol to be undefined within 
the executable file and continues processing. 

Some relocations are associated with procedure linkage table entries. These 
entries are used for direct function calls rather than for references to function 
addresses. These relocations are not treated in the special way described above 
because the dynamic linker must not redirect procedure linkage table entries to 
point to themselves. 
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Procedure Linkage Table 

The procedure linkage table is a repository for short sequences of code that pro¬ 
vide convenient access to GOTP entries. A procedure linkage table ("PLT") entry 
is a sequence of instructions that passes control on to a procedure identified by a 
particular GOTP entry. The benefit of a PLT entry is that it provides an address 
(the address of its first instruction) to which control can simply be transferred (as 
by a bsr instruction, for example) in order to invoke a GOTP entry with the 
appropriate protocol. 

It is usually better to access a GOTP entry directly rather than indirectly through a PLT 
entry. However, there are some situations in which a PLT entry can be useful. 

■ When code is compiled for inclusion in an executable file (and, in particular, 
not for inclusion in a shared object), it is generally best to compile a call into 
simply a bsr instruction, under the assumption that most calls from outside 
of all shared objects will be to procedures that are not in a shared object. If it 
turns out for such a call that the procedure being called is in a shared object, 
a PLT entry can be created by the link editor, and the bsr instruction can sim¬ 
ply be adjusted to reference the PLT entry. 

■ When code is compiled for inclusion in a shared object, the compiler can 
emit instructions to access the GOTP entry directly. It may be useful, how¬ 
ever, for either convenience of the compiler or compactness of the call (when 
many are made statically to the same GOTP entry), to use simply a bsr 
instruction and a PLT entry. 

The procedure linkage table is unlike a normal table in one respect—its entries 
are not necessarily all the same size. (Nevertheless, typically the entries will all 
be the same size.) The form of a typical PLT entry, for a hypothetical procedure 
named "name," is shown below, as if it were written in assembly language. 
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Figure 5-10: PLT Entry 


name: or. u 

#rll,#r0,#hil6(name#gotp) 

Id 

#rll,#rll,#lol6(name#gotp) 

jmp 

fell 


Although the instruction sequence shown above is only one of many possible 
sequences, the following points will invariably be true: 

■ The GOTP entry for the procedure is referenced absolutely. Because the glo¬ 
bal offset table for a shared object may reside at different locations in dif¬ 
ferent processes, the PLT entry code cannot be shared by different processes. 

■ Register #rll is used to load the contents of the GOTP entry. 

■ No register other than #rll is changed by the PLT entry sequence. 

Executable files and shared object files have separate procedure linkage tables, 
just as they have separate global offset tables. The treatment by the link editor 
and dynamic linker can vary in the two different cases. The procedure linkage 
table in an executable file can be relocated by the link editor, so it can be placed in 
the text area and shared by all processes executing that file. Note that, in this 
case, the dynamic linker doesn't act on the procedure linkage table at all. 

Because the PLT entry refers to absolute addresses in the global offset table, how¬ 
ever, the procedure linkage table in a shared object file cannot be relocated until 
the shared object has had its memory assigned by the dynamic linker. In the 
shared object case, the link editor constructs the procedure linkage table in a seg¬ 
ment that is initially writable but not executable. The link editor records the 
extent of the PLT region with the dt_88k_pltstart and dt_88k_pltend informa¬ 
tion. The dynamic linker loads the shared object, performs relocations (including 
those on the procedure linkage table), then uses mprotect (KE_OS) to change the 
segment containing the procedure linkage table from writable to executable. 

Note that the area of memory subject to being changed from writable to execut¬ 
able is the area containing the PLT region, rounded outward on each end to a 64K 
boundary. 
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The link editor is responsible for contributing text description information to 
describe the code that it creates, namely the PLT entries, GOTP binding entries, 
and GOTP binding helper routine. 
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Additional Entry Points 

There are no additional entry points required by the Motorola 88000 Processor 
Supplement. 


Support Routines 

Besides operating system services, libsys contains the following processor- 
specific support routines. The routines are also accessible named with a leading 
underscore. 


Figure 6-1: libsys Support Routines 

getpsr sbrk setpsr 


unsigned getpsr(void); 

This function returns the current contents of the Processor Status 
Register (PSR). 

char *sbrk(int incr); 

This function adds incr bytes to the break value and changes the 
allocated space accordingly. Incr can be negative, in which case the 
amount of allocated space is decreased. The break value is the 
address of the first location beyond the end of the data segment. The 
amount of allocated space increases as the break value increases. 
Newly allocated space is set to zero. If, however, the same memory 
space is reallocated to the same process, its contents are undefined. 
Upon successful completion, sbrk returns the old break value. Other¬ 
wise, it returns -1 and sets errno to indicate the error. 

unsigned setpsr(unsigned psr); 

This function sets several bits in the Processor Status Register (PSR) of 
the calling process. These bits control certain aspects of the execution 
of the process. The bits that can be set are the SER, C, BO, and MXM 
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bits; the precise semantics of these bits are defined in the MC88100 
User's Manual. 

The parameter psr is the bitwise inclusive OR of one or more of the 
following values: psr_ser, psr c, psr_mxm, or psr bo. (See 
<m88kbcs.h>.) 

Setting the SER bit (psr ser) turns on serial mode. Clearing this bit 
allows concurrent operation. 

Setting the C (psr_c) bit sets the carry bit to one; clearing this bit 
zeroes the carry bit. 

Setting the MXM bit (psr_mxm) disables misaligned access exceptions. 
Clearing this bit enables misaligned access exceptions; in this mode a 
misaligned access causes the system to deliver a sigbus signal to the 
process. 

Setting the BO bit (psr_bo) causes the current byte order to be Little- 
Endian; clearing the BO bit causes the current byte order to be Big- 
Endian. Regardless of the setting of the BO bit, all interfaces to or 
from the system are always in Big-Endian order: all fields in struc¬ 
tures, signal frames, etc. 

All bits in the psr parameter except SER, C, BO, and MXM are ignored. 

The setpsr call returns the previous value of the Processor Status 
Register. 
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Global Data Symbols 

The libsys library requires that some global external data objects be defined for the 
routines to work properly. In addition to the corresponding data symbols listed in 
the System V ABI, the following symbols must be provided in the system library on 
all ABI-conforming systems implemented with the Motorola 88000 processor archi¬ 
tecture. Declarations for the data objects listed below can be found in the Data 
Definitions section of this chapter or immediately following the table. 


Figure 6-2: libsys, Global External Data Symbols 

_flt_rounds_huge_val 


Application Constraints 

As described above, libsys provides symbols for applications. In a few cases, 
however, an executable is obliged to provide symbols for the library. In addition 
to the application-provided symbols listed in this section of the System V ABI, 
conforming applications on the Motorola 88000 processor architecture are also 
required to provide the following symbols. 

extern end; 

This symbol refers neither to a routine nor to a location with interest¬ 
ing contents. Instead, its address must correspond to the beginning of 
a program's dynamic allocation area, called the heap. Typically, the 
heap begins immediately after the data segment of the program's exe¬ 
cutable file. This value is normally provided by the static linker. 

extern const int _lib_version; 

This variable's value specifies the compilation and execution mode for 
the program. If the value is zero, the program wants to preserve the 
semantics of older (pre-ANSI) C, where conflicts exist with ANSI. Oth¬ 
erwise, the value is non-zero, and the program wants ANSI C seman¬ 
tics. This value is normally provided by the compiler. 
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Additional Support Routines 

There are no additional support routines required by the Motorola 88000 Proces¬ 
sor Supplement. 
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Data Definitions 

This section contains standard header files that describe system data. These files 
are referred to by their names in angle brackets: <name.h> and <sys/ name.h>. 
Included in these headers are macro definitions and data definitions. 

The data objects described in this section are part of the interface between an 
ABI-conforming application and the underlying ABI-conforming system where it 
will run. While an ABI-conforming system must provide these interfaces, it is not 
required to contain the actual header files referenced here. 

ANSI C serves as the ABI reference programming language, and data definitions 
are specificed in ANSI C format. The C language is used here as a convenient 
notation. Using a C language description of these data objects does not preclude 
their use by other programming languages. 


Figure6-3: <assert.h> 
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Figure 6-9: <errno.h>, Part 4 of 4 



♦define 

ELIBMAX 

86 

♦define 

ELIBEXEC 

87 

♦define 

EINPROGRESS 

128 

♦define 

EALREADY 

129 

♦define 

ENOTSOCK 

130 

♦define 

EDESTADDRREQ 

131 

♦define 

EMSGSIZE 

132 

♦define 

EPROTOTYPE 

133 

♦define 

ENOPROTOOPT 

134 

♦define 

EPROTONOSDPPORT 

♦define 

ESOCKTNOSUPPORT 

♦define 

EOPNOTSUPP 

137 

♦define 

EPFNOSUPPORT 

138 

♦define 

EAFNOSUPPORT 

139 

♦define 

EADDRINUSE 

140 

♦define 

EADDRNOTAVAIL 

141 

♦define 

ENETDOWN 

142 

♦define 

ENETUNREACH 

143 

♦define 

ENETRESET 

144 

♦define 

ECONNABORTED 

145 

♦define 

ECONNRESET 

146 

♦define 

ENOBUFS 

147 

♦define 

EISCONN 

148 

♦define 

ENOTCONN 

149 

♦define 

ESHUTDOWN 

150 

♦define 

ETOOMANYREFS 

151 

♦define 

ETIMEDOUT 

152 

♦define 

ECONNREFUSED 

153 

♦define 

EHOSTDOWN 

156 

♦define 

EHOSTUNREACH 

157 

♦define 

EPROCLIM 

159 

♦define 

EUSERS 

160 

♦define 

EDQUOT 

161 

♦define 

EPOWERFAIL 

163 
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NOTE 


The following struct flock is defined differently than in the 88open Object 
Compatibility Standard. 


Figure 6-11: <fcnti. h>, Part 2 of 2 



Figure6-12: <fioat.h> 
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Figure 6-13: <fmtmsg.h> 



fdefine 

MMNULL 

0L 

fdefine 

MMHARD 

OxOOOOOOOlL 

fdefine 

MMSOFT 

0x00000002L 

fdefine 

MMFIRM 

Ox00000004L 

fdefine 

MMRECOVER 

OxOOOOOlOOL 

fdefine 

MMJJRECOV 

Ox00000200L 

fdefine 

MM_APPL 

Ox00000008L 

fdefine 

MMJCJTIL 

OxOOOOOOlOL 

fdefine 

MMJOPSYS 

Ox00000020L 

fdefine 

MM_PRINT 

Ox00000040L 

fdefine 

MM_CONSOLE 

Ox00000080L 

fdefine 

MM_NOSEV 

0 

fdefine 

MM_HALT 

1 

fdefine 

MM_ERROR 

2 

fdefine 

MM_WARNING 

3 

fdefine 

MM_INFO 

4 

fdefine 

MMJNULLLBL 

((char *) 0) 

fdefine 

MM_NULLSEV 

MM_NOSEV 

fdefine 

MM_NULLMC 

0L 

fdefine 

MM_NULLTXT 

((char *) 0) 

fdefine 

MM_NULLACT 

((char *) 0) 

fdefine 

MM_NULLTAG 

((char *) 0) 

fdefine 

MM_NOTOK 

-1 

fdefine 

MM_OK 

0x00 

fdefine 

MM_NOMSG 

0x01 

fdefine 

MM NOCON 

0x04 
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#define FTW_PHYS 01 

#define FTWMOUNT 02 

#define FTW__CHDIR 04 

fdefine FTW_DEPTH OH 

#define FTWF 0 

#define FTW_D 1 

#define FTW_DNR 2 

fdefine FTW_NS 3 

fdefine FTW_SL 4 

fdefine FTW_DP 6 

fdefine FTW_SLN 7 

struct FTW 

{ 

int quit; 

int base; 

int level; 

}; 


5 6-15: <grp.h> 


struct group { 

char *gr_name; 
char *gr_passwc 
gid_t gr_gid; 


System Data Interfaces 


NOTE 


The following struct ipc_perm is defined differently than in the 88open 
Object Compatibility Standard. 


Figure 6-16: <sys/ipc.h> 



struct ipcjperm { 



uid t 

uid; 


gid_t 

gid; 


uid_t 

cuid; 


gid t 

cgid; 


mode_t 

mode; 


unsigned long 

seq; 


key t 

key; 

}; 

long 

pad[4]; 

♦define 

IPC_CREAT 

0001000 

♦define 

IPCJEXCL 

0002000 

♦define 

IPC_NOWAIT 

0004000 

♦define 

IPC_ALLOC 

0100000 

♦define 

IPC_PRIVATE 

(key_t)0 

♦define 

IPC_RMID 

10 

♦define 

IPC_SET 

11 

♦define 

IPC STAT 

12 
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Figure 6-19: <limits.h> 



♦define MB LEN MAX 5 


#undef ARGMAX 
#undef CHILDMAX 
fundef MAXCANON 
#undef NGROUP S_MAX 
#undef LINKJMAX 
#undef NAME_MAX 
fundef OPEN_MAX 
fundef PASSJMAX 
fundef PATH_MAX 
fundef PIPE_BUF 
fundef MAX_INPUT 

/* the fundef-fed values vary and should be 

retrieved using sysconf() or pathconf() */ 


♦define 

_POSIX_ARG_MAX 

4096 

♦define 

_POSIX_CHILD_MAX 

6 

♦define 

_POSIX_LINK 

MAX 

8 

♦define 

_POSIX_MAX_CANON 

255 

♦define 

JPOSIX_MAX_INPUT 

255 

♦define 

_POSIX_NAME 

MAX 

14 

♦define 

_POSIX_NGROUPS_MAX 

0 

♦define 

_POSIX_OPEN 

MAX 

16 

♦define 

_POSIX_PATH 

MAX 

255 

♦define 

_POSIX_PIPE_ 

_BUF 

512 

♦define 

NL_ARGMAX 

9 


♦define 

NL_LANGMAX 

14 


♦define 

NL_MSGMAX 

32767 


♦define 

NLNMAX 

1 


♦define 

NL_SETMAX 

255 


♦define 

NLTEXTMAX 

255 


♦define 

NZERO 

20 


♦define 

TMPMAX 

17576 


♦define 

FCHAR MAX 

1048576 
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char * decimal_point; 

char *thousandssep; 

char * grouping; 

char *int_curr_synibol, 
char * currency_symbol, 

char *mon_decimal_poi] 
char *mon_thousands_s< 
char *mon_gr ouping ; 

char *positive_sign; 
char * negative_sign ; 
char intfracdigits; 
char frac_digits; 
char p_cs_jprecedes; 

char p_sep_by_space; 
char n_cs_precedes; 

char n_sep_by_space; 
char p_sign_posn; 
char n_signjposn; 

} lconv; 

fdefine LC_CTYPE 0 

#define LC_NUMERIC 3 
idefine LC_TIME 2 

#define LC_COLLATE 1 
#define LC MONETARY 4 
♦define LCMESSAGES 5 
♦define LC_ALL 6 

♦define NULL 0 
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Figure 6-25: <sys/mount .h> 
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The following struct msqid_ds is defined differently than in the 88open 
note Object Compatibility Standard. 
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Figure 6-28: <netconfig.h>, Part 2 of 2 



#define 

♦define 

♦define 

♦define 

♦define 

♦define 

♦define 

♦define 

♦define 

♦define 

♦define 

♦define 

♦define 

♦define 

♦define 

♦define 

♦define 

♦define 

♦define 

♦define 

♦define 

♦define 

♦define 

♦define 

♦define 

♦define 

♦define 




NCNOPROTOFMLY 

»l_fl 

NC_LOOPBACK 

"loopback" 

NC_INET 

"inet" 

NC_IMPLINK 

"implink" 

NC_PUP 

"pup" 

NC_CHAOS 

"chaos" 

NC_NS 

"ns" 

NC_NBS 

"nbs" 

NC_ECMA 

"ecma" 

NC_DATAKIT 

"datakit" 

NC_CCITT 

"ccitt" 

NC_SNA 

"sna" 

NC_DECNET 

"decnet" 

NC_DLI 

"dli" 

NC_LAT 

"lat" 

NC_HYLINK 

"hylink" 

NC_APPLETALK 

"appletalk' 

NCNIT 

"nit" 

NC_IEEE802 

"ieee802" 

NC_OSI 

"osi" 

NC_X25 

"x25" 

NC_0SINET 

"osinet" 

NCjGOSIP 

"gosip" 

NC_NOPROTO 


NC_TCP 

"tcp" 

NC_UDP 

"udp" 

NC_ICMP 

"icmp" 
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struct ndaddrlist { 

int ncnt; 

struct netbuf *n_addrs; 

}; 

struct nd_hostservlist { 
int h_cnt; 

struct nd_hostserv *h_ho£ 

In¬ 
struct ndhostserv { 

char *h_host; 
char *h_serv; 

}; 


#define NDBADARG -2 

#define ND_NOMEM -1 

♦define NDOK 0 

♦define NDNOHOST 1 

♦define ND_NOSERV 2 

♦define NDNOSYM 3 

♦define ND_OPEN 4 

♦define ND_ACCESS 5 

♦define NDUKNWN 6 

♦define ND_NOCTRL 7 

♦define NDFAILCTRL 8 

♦define NDSYSTEM 9 

♦define ND_HOSTSERV 0 

♦define ND_HOSTSERVLIST 1 

♦define ND_ADDR 2 

♦define ND_ADDRL1ST 3 

♦define ND_SETJ8ROADCAST 1 

♦define ND_SET_RESERVEDPORT 2 
♦define ND_CHECK_RESERVEDPORT 3 
♦define ND_MERGEADDR 4 

♦define HOSTSELF "\\1 

♦define HOST_ANY "\\2 

♦define HOST BROADCAST "\\3 
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Figure 6-32: <poii.h> 



struct pollfd { 



int fd; 

short events; 


}; 

short revents 

; 

#define 

POLLIN 

0x0001 

#define 

POLLPRI 

0x0002 

♦define 

POLLOUT 

0x0004 

♦define 

POLLRDNORM 

0x0040 

♦define 

POLLWRNORM 

POLLOUT 

♦define 

POLLRDBAND 

0x0080 

♦define 

POLLWRBAND 

0x0100 

♦define 

POLLNORM 

POLLRDNORM 

♦define 

POLLERR 

0x0008 

♦define 

POLLHUP 

0x0010 

♦define 

POLLNVAL 

0x0020 
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♦define 

P_INITPID 

1 

♦define 

P_INITUID 

0 

♦define 

P_INITPGID 

0 

♦define 

P_MYID 

(-1) 

typedef 

long id t; 


typedef 

enum idtype { 
P_PID, 

P_PPID, 

PPGID, 

P_SID, 

P_CID, 

P_UID, 

P_GID, 

PALL 


} idtype_t; 


typedef 

enum idop { 
POPDIFF, 
POPAND, 
POP_OR, 

POPXOR 


} idop t 



typedef 

struct procset 

{ 


idop t 

p_op; 


idtypet 

p_lidt 


id_t 

p_lid; 


idtype_t 

p_ridt 


id t 

p_rid; 

I Drocset t; 






typedef unsigned int 

gr< 

♦define 

NGREG 


38 

typedef greg t 


gr< 

♦define 

RJRO 

0 


♦define 

R_R1 

1 


♦define 

R_R2 

2 


♦define 

R_R3 

3 


♦define 

R_R4 

4 


♦define 

R R5 

5 


♦define 

R_R6 

6 


♦define 

R_R7 

7 


♦define 

R_R8 

8 


♦define 

R_R9 

9 


♦define 

R_R10 

10 


♦define 

R_R11 

11 


♦define 

R_R12 

12 


♦define 

R_R13 

13 


♦define 

R_R14 

14 


♦define 

R_R15 

15 


♦define 

R_R16 

16 


♦define 

RJR17 

17 


♦define 

R_R18 

18 


♦define 

R_R19 

19 


♦define 

R_R20 

20 


♦define 

R_R21 

21 


♦define 

R_R22 

22 


♦define 

RR23 

23 


♦define 

R_R24 

24 


♦define 

R R25 

25 




#define 

RR26 

26 


#define 

RR27 

27 


#define 

RR28 

28 


idefine 

RR29 

29 


#define 

RR30 

30 


#define 

R_R31 

31 


#define 

RXIP 

32 


#define 

R_NIP 

33 


#define 

R_FIP 

34 


idefine 

R_PSR 

35 


#define 

R_FPSR 

36 


#define 

R_FPCR 

37 


typedef 

struct 

dfltinfo { 


unsigned int 

dma 


unsigned int 

dmt, 


unsigned int 

dmd 

} dfltinfo_t; 



typedef struct 

fpifltinfo 


unsigned int 

fpr] 


unsigned int 

fpr 


unsigned int 

fpil 

} fpifltinfo t; 
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Figure 6-37: <sys/resource.h> 


#define RLIMIT_CPU 
♦define RLIMIT_FSIZE 
♦define RLIMIT_DATA 
♦define RL IMI T_STACK 
♦define RLIMIT_CORE 
♦define RLIMIT_NOFILE 
♦define RLIMIT_VMEM 
♦define RLIMIT AS 


0 

1 

2 

3 

4 

5 

6 

RLIMIT VMEM 


struct rlimit { 

rlim_t rlim_cur; 
rlim_t rlimmax; 

}; 

typedef unsigned long rlim_t; 
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Figure 6-41: <rpc.h>, Part 4 of 12 



enum clnt_stat { 

RPC_SUCCESS=0 , 
RPC_CANTENC0DEARGS=1, 
RPC_CANTDEC0DERES=2, 
RPC_CANTSEND=3, 
RPC_CANTRECV=4, 

RPC_T IMED0UT=5 , 

RPC_INTR=18, 

RPC_VERSMI SMATCH= 6, 
RPC_AUTHERR0R=7, 
RPC_PR0GUNAVAIL=8, 
RPCJPROGVERSMISMATCH=9, 
RPC_PROCUNAVAIL=l0, 
RPC_CANTDECODEARGS=ll, 
RPC__SYSTEMERROR=12, 
RPC_UNKNOWNHOST=l3, 
RPC_UNKNOWNPROTO= 17, 
RPC_UNKNOWNADDR=l9, 
RPC_NOBROADCAST=21, 
RPC_RPCBFAILURE=14, 
RPC_PROGNOTREGISTERED=15, 
RP CN 2AXLATEFAILURE=2 2, 
RPC_UDERR0R=2 3, 
RPC_TLIERROR=20, 

RPC FAILED=16 


}; 

♦define RPC PMAPFAILURE RPC RPCBFAILURE 
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fdefine _RPC_NONE 0 
#define _RPC_NETPATH 1 
#define _RPC_VISIBLE 2 
#define _RPC_CIRCUIT_V 3 
#define _RPC_DATAGRAM_V 4 
fdefine JRPCCIRCUITN 5 
#define _RPC_DATAGRAM_N 6 
#define _RPC_TCP 7 
#define _RPC_UDP 8 

#define RPC_ANYSOCK -1 
#define RPCANYFD RPC_ANYS< 


struct rpc_err { 

enum clnt_stat re_statu 
union { 

struct { 
int errno; 
int t errno; 


} RE_err; 


enum auth__stat I 
struct { 

unsigned long 
unsigned long 
} RE_vers; 
struct { 
long sir- 
long s2; 

1 RE lb; 















cceptea_rep-Ly i 
struct opaque_< 
enum accept_st< 
union { 
struct { 
unsigned lon< 
unsigned lon< 
} AR_versions, 
struct { 
char *where; 
xdrproc_t pr< 
} AR_results; 

} ru; 


ejected_reply \ 
enum reject_sti 
union { 
struct { 
unsigned lon< 
unsigned lone 
} RJ_versions, 
enum auth stal 
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Figure 6-49: <rpc.h>, Part 12 of 12 



typedef struct { 

enum xdr_op x_op; 
struct xdr_ops { 

int (*x_getlong)(); 

int (* x put long) () ; 

int (*x_getbytes) () ; 

int (*x_putbytes)(); 

unsigned int (*x_getpostn)() ; 
int (*x_setpostn)(); 

long * (*x inline)(); 

void (*x_destroy) (); 

} *x_ops; 
char x_public; 
char x_private; 
char x_base; 
int x_handy; 

} XDR; 

typedef int (*xdrproc_t)() 

fdefine NULL_xdrproc_t ((xdrproc_t)0) 

#define authdestroy(auth) ((*((auth)->ah_ops->ah_destroy))(auth)) 
fdefine clnt_call(rh, proc, xargs, argsp, xres, resp, secs) \ 

((*(rh)->cl ops->cl call)(rh, proc r xargs, argsp, xres, resp, secs)) 
fdefine clnt_freeres(rh, xres, resp) ((*(rh)->cl_ops->cl_freeres)(rh, xres, resp)) 
fdefine clntgeterr(rh, errp) ((*(rh)->cl_ops->cl_geterr)(rh, errp)) 
fdefine clntcontrol(cl, rq, in) ((* (cl)->cl_ops->cl_control) (cl, rq, in)) 

fdefine clnt_destroy(rh) ((*(rh)->cl_ops->cl_destroy)(rh)) 

fdefine svc_destroy(xprt) (*(xprt)->xp_ops->xp_destroy)(xprt) 

fdefine svcfreeargs(xprt, xargs, argsp) \ 

(*(xprt)->xpops->xp_freeargs)((xprt), (xargs), (argsp)) 
fdefine svcgetargs(xprt, xargs, argsp) \ 

(*(xprt)->xp_ops->xp_getargs)((xprt), (xargs), (argsp)) 
fdefine svcgetrpccaller(x) (&(x)->xp_rtaddr) 

fdefine xdr_getpos(xdrs) (*(xdrs)->x_ops->x_getpostn)(xdrs) 

fdefine xdr_setpos(xdrs, pos) (*(xdrs)->x_ops->x_setpostn)(xdrs, pos) 
fdefine xdr_inline(xdrs, len) (*(xdrs)->x_ops->x_inline)(xdrs, len) 
fdefine xdr_destroy(xdrs) (*(xdrs)->x_ops->x_destroy)(xdrs) 
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Figure 6-50: <search.h> 
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NOTE 


The following struct semid_ds is defined differently than in the 88open 
Object Compatibility Standard. 


Figure 6-51: <sys/sem.h> 



♦define 

SEMUNDO 

010000 

♦define 

GETNCNT 

3 

♦define 

GETPID 

4 

♦define 

GETVAL 

5 

♦define 

GETALL 

6 

♦define 

GETZCNT 

7 

♦define 

SETVAL 

8 

♦define 

SETALL 

9 

struct semid ds { 



struct ipcjperm sem_permi 


struct sem 

♦sembase; 


char 

sem pad[2]; 


unsigned short 

sem_nsems; 


time t 

sem_otime; 


long 

sem_ousec; 


time_t 

sem ctime; 


long 

sem_cusec; 


long 

pad[4]; 


}; 


struct 


sem { 
unsigned 
pid_t 
unsigned 
unsigned 


short semval; 

sempid; 
short semncnt; 
short semzcnt; 


In¬ 


struct sernbuf { 

unsigned short sem_num; 
short sem_op; 

short sem_flg; 
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The following struct shmid_ds is defined differently than in the 88open 
note Object Compatibility Standard. 
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Figure 6-54: <sigaction.h> 
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Figure 6-55: <sys/siginfo.h>, Part 1 of 3 



#define 

SI_FROMUSER(sip) ((sip)->si_code <= 0) 

♦define 

SI FROMKERNEL(sip) ((sip)->si code > 0) 

♦define 

SIJJSER 

0 

♦define 

ILL_ILLOPC 

1 

♦define 

ILLJPRVOPC 

2 

♦define 

FPE_INTOVF 

0x80000001 

♦define 

FPE_INTDIV 

0x80000002 

♦define 

FPE_FLTSUB 

0x80000003 

♦define 

FPE_FLTRES 

0x01 

♦define 

FPE_FLTOW 

0x02 

♦define 

FPE_FLTUND 

0x04 

♦define 

FPE_FLTDIV 

0x08 

♦define 

FPE_FLTINV 

0x10 

♦define 

FPE_PRIWIO 

0x20 

♦define 

FPE_UNIMPL 

0x40 

♦define 

FPEJFLTNAN 

0x80 

♦define 

SEGVMZVPERR 

0x01 

♦define 

SEGVACCERR 

0x02 

♦define 

SEGV_CODE 

0x04 

♦define 

SEGV_DATA 

0x08 

♦define 

BU S_ADRALN 

0x01 

♦define 

BUS_ADRERR 

0x02 

♦define 

BUS_OBJERR 

0x03 

♦define 

BUS_ALIGN 

0x04 

♦define 

BUS PROT 

0x08 
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ie CLD_EXITED 1 
ie CLD_KILLED 2 
ie CLD_DUMPED 3 
ie CLD_TRAPPED 4 
ie CLD_STOPPED 5 
ie CLD_CONTINUED 6 

ie POLL_IN 1 
ie POLL OUT 2 
ie POLL_MSG 3 
ie POLL_ERR 4 
le POLL_PRI 5 
ie POLL_HUP 6 

le SI MAXSZ 256 
ie SI_PAD ((s: 


sf struct { 

int eb_signo; 

int eb code; 

union { 

int _pa< 
dfltinfo_t 
fpifltinfo 
} _eb_registers; 











struct siginfo { 
int si_signo; 

int si_errno; 

int si_code; 

int si_machinexcep; 

union { 

int pad [ S I_PAD ] ; 

struct { 

pid_t _pid; 
union { 

struct { 

uid_t _uid; 

} Jcill; 

struct { 

clock_t _utime 

int _statu 

clock_t _stime 

} _cld; 

} pdata; 

} proc; 
struct { 

int _fd; 
long band; 

} _file; 
struct { 

int _ncodes; 

exblk_t *_exblks; 

} machine; 




le 

SIGHUP 

1 

le 

SIGINT 

2 

le 

SIGQUIT 

3 

le 

SIGILL 

4 

le 

SIGTRAP 

5 

le 

SIGIOT 

6 

le 

SIGABRT 

6 

le 

SIGEMT 

7 

le 

SIGFPE 

8 

le 

SIGKILL 

9 

le 

SIGBUS 

10 

le 

SIGSEGV 

11 

le 

SIGSYS 

12 

ie 

SIGPIPE 

13 

le 

SIGALRM 

14 

le 

SIGTERM 

15 

le 

SIGUSR1 

16 

le 

SIGUSR2 

17 

le 

SIGCLD 

18 

le 

SIGCHLD 

18 

le 

SIGPWR 

19 

le 

SIGWINCH 

20 

ie 

SIGPOLL 

22 

ie 

SIGSTOP 

23 

ie 

SIGTSTP 

24 

ie 

SIGCONT 

25 

ie 

SIGTTIN 

26 

le 

SIGTTOU 

27 

ie 

SIGURG 

33 

ie 

SIGIO 

34 

ie 

SIGXCPU 

35 

le 

SIGXFSZ 

36 

ie 

SIGVTALRM 

37 

ie 

SIGPROF 

38 

le 

SIGLOST 

40 











stat { 
dev_t 

st_dev; 

ino t 

st ino; 

mode t 

st mode; 

nlink t 

st nlink; 

uid_t 

st_uid; 

gid t 

st gid; 

dev_t 

st rdev; 

off t 

st size; 

time t 

st atime; 

unsigned long 

st_ausec; 

time_t 

st_mtime; 

unsigned long 

st_musec; 

time_t 

st_ctime; 

unsigned long 

st_cusec; 

timestruc_t 

st_atim; 

timestruc_t 

st_mtim; 

timestruc_t 

st ctim; 

long 

st blksiz< 

long 

st_blocks, 

char 

st_fstype 

char 

st paddinc 
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Figure 6-61: <sys/stat .h>, Part 2 of 2 



♦define 

S_IFMT 

OxFOOO 





♦define 

S_IFIFO 

0x1000 





#define 

S_IFCHR 

0x2000 





♦define 

S_IFDIR 

0x4000 





♦define 

S_IFBLK 

0x6000 





♦define 

S_IFREG 

0x8000 





♦define 

S_IFLNK 

OxAOOO 





♦define 

S_ISUID 

04000 





♦define 

S_ISGID 

02000 





♦define 

S_ISVTX 

01000 





♦define 

S_IRWXU 

00700 





♦define 

S_IRUSR 

00400 





♦define 

S_IWUSR 

00200 





♦define 

S_IXUSR 

00100 





♦define 

S_IRWXG 

00070 





♦define 

S_IRGRP 

00040 





♦define 

S_IWGRP 

00020 





♦define 

S_IXGRP 

00010 





♦define 

S_IRWXO 

00007 





♦define 

S_IROTH 

00004 





♦define 

S__IWOTH 

00002 





♦define 

S_IXOTH 

00001 





♦define 

S_ISFIFO (mode) 

( (mode 

& 

S 

IFMT) == S_ 

IFIFO) 

♦define 

S__I SCHR (mode) 

((mode 

& 

S_ 

IFMT) == S 

IFCHR) 

♦define 

S_I SDIR (mode) 

((mode 

& 

S 

IFMT) == S 

IFDIR) 

♦define 

S__ISBLK (mode) 

( (mode 

& 

S_ 

IFMT) == S 

IFBLK) 

♦define 

S ISREG(mode) 

((mode 

& 

s 

IFMT) == S 

IFREG) 
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Figure 6-63: <stdarg.h> 



The member next arg is the number of words from the beginning of the argu¬ 
ment list to the beginning of the next argument to be returned by va arg. 
next arg shall always have a nonnegative value. mem_ptr points at the begin¬ 
ning of the argument area. reg_ptr points at a structure of the following form: 

struct {int #r2, #r3, #r4, #r5, #r6, #r7, #r8, #r9;} 

where each member contains the value at procedure entry of the indicated regis¬ 
ter, if that register holds a portion of the variable argument list represented by 
the va_list structure. A procedure receiving a va__list structure shall not refer 
to members of the structure pointed at by reg_ptr that do not correspond to 
portions of the variable argument list that the va_list structure represents. The 
structure pointed at by reg_ptr shall be 8-byte aligned. 


NOTE 


The procedure using the va_iist structure determines, for each argument 
of the variable argument list, whether to fetch the argument value from the 
memory area or the register area, according to the position of the argument 
in the argument list and the type of the argument (including size, alignment, 
and whether it is a structure or union). 
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Figure 6-67: <stropts.h>, Part 1 of 4 



♦define 

RNORM 

0x000 

#define 

RMSGD 

0x001 

#define 

RMSGN 

0x002 

♦define 

RMODEMASK 

0x003 

♦define 

RPROTDAT 

0x004 

♦define 

RPROTDIS 

0x008 

♦define 

RPROTNORM 

0x010 

♦define 

FLUSHR 

0x01 

♦define 

FLUSHW 

0x02 

♦define 

FLUSHRW 

0x03 

♦define 

S_INPUT 

0x0001 

♦define 

S_HIPRI 

0x0002 

♦define 

S_OUTPUT 

0x0004 

♦define 

S_MSG 

0x0008 

♦define 

SJERROR 

0x0010 

♦define 

S__HANGUP 

0x0020 

♦define 

S_RDNORM 

0x0040 

♦define 

S__WRNORM 

S_OUTPUT 

♦define 

SJRDBAND 

0x0080 

♦define 

SJWRBAND 

0x0100 

♦define 

SJ3ANDURG 

0x0200 

♦define 

RS_HIPRI 

1 

♦define 

MSG_HIPRI 

0x01 

♦define 

MSG_ANY 

0x02 

♦define 

MSG_BAND 

0x04 

♦define 

MORECTL 

1 

♦define 

MOREDATA 

2 

♦define 

MUXID ALL 

(-D 
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Figure 6-68: <stropts .h>, Part 2 of 4 


r~ 

#define 

#define 

#define 

#define 

#define 

#define 

#define 

#define 

♦define 

#define 

#define 

#define 

#define 

#define 

♦define 

♦define 

♦define 

♦define 

♦define 

♦define 

♦define 

♦define 

♦define 

♦define 

♦define 

♦define 

♦define 

♦define 

♦define 

♦define 

V 


STR 

IJSfREAD 

IJPUSH 

I_POP 

I_LOOK 

I_FLUSH 

I_SRDOPT 

I_GRDOPT 

I_STR 

I_SETSIG 

I_GETSIG 

I_FIND 

I_LINK 

I_UNLINK 

I_RECVFD 

IJPEEK 

I_FDINSERT 

ISENDFD 

I_SWROPT 

I_GWROPT 

ILIST 

I_PLINK 

I_P UNLINK 

I_FLU S HBAND 

I_CKBAND 

I_GETBAND 

I_ATMARK 

I_SETCLT IME 

I_GETCLT IME 

I CANPUT 


('S'«8) 
(STR|01) 
(STR|02) 
(STR| 03) 
(STR|04) 
(STR|05) 
(STR| 06) 
(STR|07) 
(STR|010) 
(STR| Oil) 
(STR|012) 
(STR|013) 
(STR|014) 
(STR|015) 
(STR|016) 
(STR| 017) 
(STR|020) 
(STR| 021) 
(STR|023) 
(STR|024) 
(STR|025) 
(STR|026) 
(STR|027) 
(STR|034) 
(STR|035) 
(STR|036) 
(STR|037) 
(STR|040) 
(STR|041) 
(STR|042) 
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strioctl 

{ 

int 

ic cmd; 

int 

ic_timout 

int 

ic len; 

char 

*ic_dp; 


strbuf 

{ 

int 

maxlen, 

int 

len; 

char 

*buf; 


strpeek 

{ 

struct 

strbuf ctlbi 

struct 

strbuf datat 

long 

flags, 

strfdinsert { 

struct 

strbuf ctlbi 

struct 

strbuf datat 

long 

flags, 

int 

filde; 

int 

offsel 


itrrecvfd { 

int 

fd; 

uid_t 

uid; 

gid_t 

gid; 

char 

fill[8] 
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Figure 6-72: <termios .h>, Part 2 of 6 



♦define 

CNUL 

0 

♦define 

CDEL 

0377 

♦define 

CESC 

'\V 

♦define 

CINTR 

0177 

♦define 

CQUIT 

034 

♦define 

CERASE 

'♦' 

♦define 

CKILL 


♦define 

CEOT 

04 

♦define 

CEOL 

0 

♦define 

CE0L2 

0 

♦define 

CEOF 

04 

♦define 

CSTART 

021 

♦define 

CSTOP 

023 

♦define 

CSWTCH 

032 

♦define 

CNSWTCH 

0 

♦define 

CSUSP 

CTRL(' z ‘ 

♦define 

CDSUSP 

CTRL ('y' 

♦define 

CRPRNT 

CTRL (' r 1 

♦define 

CFLUSH 

CTRL (' o' 

♦define 

CWERASE 

CTRL (' w' 

♦define 

CLNEXT 

CTRL (' v' 

♦define 

IGNBRK 

0000001 

♦define 

BRKINT 

0000002 

♦define 

IGNPAR 

0000004 

♦define 

PARMRK 

0000010 

♦define 

INPCK 

0000020 

♦define 

ISTRIP 

0000040 

♦define 

INLCR 

0000100 

♦define 

IGNCR 

0000200 

♦define 

ICRNL 

0000400 

♦define 

IUCLC 

0001000 

♦define 

IXON 

0002000 

♦define 

IXANY 

0004000 

♦define 

IXOFF 

0010000 

♦define 

IMAXBEL 

0020000 
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Figure 6-73: <termios.h>, Part 3 of 6 



♦define 

OPOST 

0000001 

♦define 

OLCUC 

0000002 

♦define 

ONLCR 

0000004 

♦define 

OCRNL 

0000010 

♦define 

ONOCR 

0000020 

♦define 

ONLRET 

0000040 

♦define 

OFILL 

0000100 

♦define 

OFDEL 

0000200 

♦define 

NLDLY 

0000400 

♦define 

NLO 

0 

♦define 

NL1 

0000400 

♦define 

CRDLY 

0003000 

♦define 

CRO 

0 

♦define 

CR1 

0001000 

♦define 

CR2 

0002000 

♦define 

CR3 

0003000 

♦define 

TABDLY 

0014000 

♦define 

TABO 

0 

♦define 

TAB1 

0004000 

♦define 

TAB2 

0010000 

♦define 

TAB3 

0014000 

♦define 

XTABS 

TAB3 

♦define 

BSDLY 

0020000 

♦define 

BSO 

0 

♦define 

BS1 

0020000 

♦define 

VTDLY 

0040000 

♦define 

VTO 

0 

♦define 

VT1 

0040000 

♦define 

FFDLY 

0100000 

♦define 

FFO 

0 

♦define 

FF1 

0100000 
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Figure 6-74: ctermios .h>, Part 4 of 6 



♦define 

CBAUD 

077600000 

♦define 

BO 

0 

♦define 

B50 

00200000 

♦define 

B75 

00400000 

♦define 

B110 

00600000 

♦define 

B134 

01000000 

♦define 

B150 

01200000 

♦define 

B200 

01400000 

♦define 

B300 

01600000 

♦define 

B600 

02000000 

♦define 

B1200 

02200000 

♦define 

B1800 

02400000 

♦define 

B2400 

02600000 

♦define 

B4800 

03000000 

♦define 

B9600 

03200000 

♦define 

B19200 

03400000 

♦define 

EXTA 

03400000 

♦define 

B38400 

03600000 

♦define 

EXTB 

03600000 

♦define 

CSIZE 

00000060 

♦define 

CS5 

0 

♦define 

CS6 

0000020 

♦define 

CS7 

0000040 

♦define 

CS8 

0000060 

♦define 

CSTOPB 

0000100 

♦define 

CREAD 

0000200 

♦define 

PARENB 

0000400 

♦define 

PARODD 

0001000 

♦define 

HUPCL 

0002000 

♦define 

CLOCAL 

0004000 

♦define 

LOBLK 

0010000 

♦define 

RCV1EN 

0020000 

♦define 

XMT1EN 

0040000 

♦define 

CIBAUD 

037700000000 

♦define 

PAREXT 

04000000 
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Figure 6-75: <termios .h>, Part 5 of 6 



♦define 

ISIG 

0000001 

♦define 

ICANON 

0000002 

♦define 

XCASE 

0000004 

♦define 

ECHO 

0000010 

♦define 

ECHOE 

0000020 

♦define 

ECHOK 

0000040 

♦define 

ECHONL 

0000100 

♦define 

NOFLSH 

0000200 

♦define 

TOSTOP 

0000400 

♦define 

ECHOCTL 

0001000 

♦define 

ECHOPRT 

0002000 

♦define 

ECHOKE 

0004000 

♦define 

FLUSHO 

0020000 

♦define 

PENDIN 

0040000 

♦define 

IEXTEN 

0100000 

♦define 

IOCTYPE 

OxffOO 



6-72 


Motorola 88000 PROCESSOR ABI SUPPLEMENT 



♦define 

TIOC 

('T'«8) 

♦define 

TCSANOW 

(TIOC|14; 

♦define 

TCSADRAIN 

(TIOC|15; 

#define 

TCSAFLUSH 

(TIOC 116! 

♦define 

TCIFLUSH 

0 

♦define 

TCOFLUSH 

1 

♦define 

TCIOFLUSH 

2 

♦define 

TCOOFF 

0 

♦define 

TCOON 

1 

♦define 

TCIOFF 

2 

♦define 

TCION 

3 

struct termios { 
tcflag_t 
tcflag_t 
tcflag t 
tcflag_t 
char 

cc t 

c iflag; 
c_oflag; 
c_cflag; 
c_lflag; 
c padl; 
c cc[NCC: 
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Figure 6-80: <sys/tiuser.h>, Service Types 



Figure 6-81: <sys/tiuser .h>, Transport Interface States 
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System Data Interfaces 


Figure 6-83: <sys/tiuser.h>, Error Return Values 


r \ 

#define TACCES 3 

#define TBADADDR 1 

#define TBADDATA 10 

#define TBADF 4 

#define TBADFLAG 16 

#define TBADOPT 2 

#define TBADSEQ 7 

#define TBUFOVFLW 11 

#define TFLOW 12 

#define TLOOK 9 

#define TNOADDR 5 

#define TNODATA 13 

#define TNODIS 14 

#define TNOREL 17 

#define TNOTSUPPORT 18 

#define TNOUDERR 15 

#define TOUTSTATE 6 

#define TSTATECHNG 19 

tdefine TSYSERR 8 

V___ J 
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struct t_optmgmt { 

struct netbuf opt 
long fli 

in¬ 
struct t_uderr { 

struct netbuf adc 
struct netbuf opt 
long en 

in¬ 
struct t_unitdata { 

struct netbuf ad< 
struct netbuf opl 
struct netbuf ud< 
i; 


3 6-86: <sys/tiuser .h 


♦define TBIND 1 
♦define T_CALL 3 
♦define T_DIS 4 
♦define T_INFO 7 
♦define T_OPTMGMT 2 
♦define T_UDERROR 6 
♦define T UNITDATA 5 




System Data Interfaces 


Figure 6-87: <sys/tiuser .h>, Fields of Structures 



Figure 6-88: <sys/tiuser.h>, Events Bitmasks 
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Figure 6-89: <sys/tiuser.h>, Flags 



Figure 6-90: <sys/types.h> 
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System Data Interfaces 


Figure 6-95: <unistd.h>, Part 2 of 3 



#define 

_SC_ARG_MAX 

1 

#define 

_SC_CHILD_MAX 

2 

#define 

_SC_CLK_TCK 

3 

#define 

_SC_NGROUP S_MAX 

4 

♦define 

_SC_OPEN_MAX 

5 

♦define 

_SC_JOB_CONTROL 

6 

♦define 

_SC_SAVED_IDS 

7 

♦define 

_SC_VERSION 

8 

♦define 

_SC_BCS_VERSION 

9 

♦define 

_SC_BCS_VENDOR_STAMP 

10 

♦define 

_SC_BCS_SYS_ID 

11 

♦define 

_SC__MAXUMEMV 

12 

♦define 

_SC__MAXUP ROC 

13 

♦define 

_SCjyiAXMSGSZ 

14 

♦define 

_S C_NMS GHDRS 

15 

♦define 

_SC__SHMMAXS Z 

16 

♦define 

_SC_SHMMINSZ 

17 

♦define 

_SC_S HMSEGS 

18 

♦define 

_SC__NMSYSSEM 

19 

♦define 

_SC__MAXSEMVL 

20 

♦define 

_SCJNSEMMAP 

21 

♦define 

_SC_NSEMMSL 

22 

♦define 

_SC_N SHMMNI 

23 

♦define 

_SC_ITIMER_VIRT 

24 

♦define 

_SC_ ITIMER_PROF 

25 

♦define 

_SC_TIMER_GRAN 

26 

♦define 

_SC_P HY SMEM 

27 

♦define 

_SC_AVAILMEM 

28 

♦define 

_SC_NICE 

29 

♦define 

SC MEMCTL UNIT 

30 
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System Data Interfaces 


Figure 6-100: <wait.h> 


( 

♦define WSTOPPED 0177 

♦define WCONTINUED 0010 

♦define WUNTRACED 0004 

♦define WNOHANG 0100 

♦define WNOWAIT 0200 

♦define WEXITED 0001 

♦define WTRAPPED 0002 

♦define WTRACED WTRAPPED 

♦define WSTOPFLG 0177 

♦define WCONTFLG 0177777 

♦define WSIGMASK 0177 


♦define WLOBYTE(stat) 
♦define WHIBYTE(stat) 
♦define WWORD(stat) 


((int) ((stat)&0377)) 

((int) (((stat) »8) &0377)) 
((int) ((stat))&0177777) 


♦define WCOREFLG 0200 


♦define WCOREDUMP(stat) 
♦define WEXITSTATUS(s) 
♦define WIFCONTINUED(stat) 
♦define WIFEXITED(s) 
♦define WIFSIGNALED(s) 
♦define WIFSTOPPED(s) 
♦define WSTOPSIG(s) 

♦define WTERMSlG(s) 



((stat)&WCOREFLG) 

(( (s)&0xff00)»8) 

(WWORD (stat) = =WCONTFLG) 
(WTERMSIG (s) ==0) 

(!WIFEXITED(s)&&!WIFSTOPPED(s)) 


((WTERMSIG (s) = =0x7f) && (((s)&0x80) = =0)) 
(WIFSTOPPED (S) ?WEXITSTATUS(s):0) 

((s)&0x7f) 
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Index 


88000 1:1, 3: 1,32, 43, 49, 54, 57-58, 5: 2 

88100 1:1, 3:1,18,33,54 

88200 3: 1 

A 

ABI conformance 3:1,32 
see also undefined behavior 3:1 
see also unspecified property 3:1 
absolute addresses 3: 49 
absolute code 3: 44, 5: 5 
see also position-independent code 
3:44 
address 
stack 3:41 
virtual 5:3 

addresses, absolute 3:49 
addressing, virtual (see virtual address¬ 
ing) 

addll instruction 3: 48 
aggregate 3:3 
alignment 
argument 3:24 
array 3:3 
bit-field 3:6 
COBOL data 3:11 
executable file 5: 3 
parameter 3:24 
scalar types 3: 2, 9-10 
stack frame 3: 22 
structure and union 3: 3 
allocation, dynamic stack space 3: 54 
alphabetic data class, COBOL 3:11 
alphanumeric data class, COBOL 3:11 
ANSI, C (see C language, ANSI) 

ANSI Standard X3.9-1978 3: 9 


ANSI X3.23-1985 3:13 
ANSI/IEEE Std 754-1985 3:17, 37-38 

architecture 
implementation 3:1 
processor 3:1 
restrictions 3:1 
argc 3:39 
argument 
alignment 3:24 
length 3:24 
argument area 3: 24 
offsets into 3: 24 
argument transmission 3: 24 
COBOL 3:26 
floating-point 3:25 
FORTRAN 3:25 
integer 3:25 
pointer 3:25 
structure 3:25 
union 3:25 
arguments 

bad assumptions 3: 54 
exec(BA_OS) 3:39 
function 3:18 
main 3:39 
passing 3:24 
variable list 3: 54 
argv 3:39 
array 3:3 
atexit(BA_OS) 3:39 
auxiliary vector 3: 41 

B 

base address 3:43 
BCD digits 3:15 


Index 
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Index 


behavior, undefined (see undefined 
behavior) 

Big-Endian byte order 3: 1,40, 6: 2 
BINARY alignments 3:16 
binary coded decimal digits 3:15 
BINARY data type, COBOL 3:11 
bit-field 3:5 
alignment 3:6 
allocation 3 :6 

boot parameters (see tunable parameters) 
breakpoint trap exception 3: 38 
bsr instruction 3:50 
byte order bit 3:1, 6:2 

C 

C language 
ANSI 3: 2, 38, 54 
calling sequence 3:18,54 
fundamental types 3: 2 
main 3:38 
portability 3:54 
calling sequence 3:18 
function epilogue 3: 23 
function prologue 3: 23 
function prologue and epilogue 
3: 47-48 

canonical frame address 3: 60 
char 3:2 

CHARACTER data type 3: 9, 26 
character data type 3: 26 
CHARACTER data type 3: 27 
character strings, PICTURE 3:12 
chunk, text 3: 57 
COBOL 3:11 

COBOL argument transmission 3: 26 
COBOL ASCII digits 3: 12 
COBOL calling sequence 3:18 


COBOL data types 3:11 
COBOL OCCURS clause 3:11 
COBOL result transmission 3: 28 
COBOL scalar types 3:11 
COBOL sign representation 3:12 
code generation 3:44 
code sequences 3:44 
COMMON statement 3: 9 
COMPLEX data type 3:10, 27 
COMPUTATIONAL data type, COBOL 
3: 11 

concurrent exceptions 3:33 
configuration parameters (see tunable 
parameters) 
crtO.o 3 :62 

D 

data 

process 3:29 
uninitialized 5:4 
data representation 3:1 
data types 
COBOL 3: 11 
FORTRAN 3:9 
debugging 5:1 
low-level 3:57 
debugging with tdesc 3: 57 
demand paging 3: 37 
diskettes, floppy 2:1 
DISPLAY data type, COBOL 3:11-12 
distribution media 2:1 
div instruction, restrictions 3:1 
div instruction faults 3: 37 
divu instruction, restrictions 3:1 
double 3:2 

DOUBLE COMPLEX data type 3:10, 27 
DOUBLE PRECISION data type 3: 27 
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Index 


double versus long double 3: 3 
double word 3: 22 

double zero-extension, unsigned integers 
3: 28 

double-precision 3:2 
double-precision arithmetic 3: 9 
dummy procedure 3: 25 
dynamic linking 3: 29, 5: 7 
lazy binding 5:10 
LD_BIND_NOW 5:10 
relocation 5:9 
see also dynamic linker 5: 7 
dynamic linking array tag 5: 7 
dynamic segments 3: 30, 5: 6 
dynamic stack allocation 3: 54 
signals 3:56 

E 

EBCDIC translation 3:13 
emulation, instructions 3:1 
Endian 

Big 3:1,40,6:2 
Little 6:2 

entry, procedure 3: 22 
environment 5:10 
exeC(BA_OS) 3:39 
envp 3:39 

EQUIVALENCE statement 3: 9 
exceptions 
concurrent 3:33 
data access 3: 37 
floating-point 3:37 
imprecise 3:33-34 
interface 3:32 
machine 3:33 
precise 3:33-34 
signals 3:32 


type table 3: 38 
exceptions and signals 3: 34 
exeC(BA_OS) 3:45 
interpreter 3:42 
paging 5:3 

process initialization 3: 38 
executable file, segments 5: 5 
execution mode (see processor execution 
mode) 

external memory fault exception 3: 38 

F 

faults (see traps) 
file, object (see object file) 
file offset 5: 3 
float 3:2 
floating-point 3:2 
argument transmission 3: 25 
IEEE 3:17,37-38 
result transmission 3: 27 
floating-point exceptions 3: 37 
formats 
array 3:3 
structure 3:3 
union 3:3 

FORTRAN argument transmission 3: 25 
FORTRAN calling sequence 3:18 
FORTRAN character data type 3: 26 
FORTRAN dummy procedure 3: 25 
FORTRAN language 3:9-10 
FORTRAN result transmission 3: 27 
FORTRAN scalar types 3: 9 
frame pointer. 3: 49 
frame pointer 3: 61 
frame size, dynamic 3: 54 
function addresses 5:14 
function arguments (see arguments) 


Index 
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function call, code 3:50 
function linkage (see calling sequence) 
function prologue and epilogue (see cal¬ 
ling sequence) 

G 

gate vector fault exception 3: 38 
general purpose registers 3:18 
getpsr() 6: i 

global offset table 3:45, 4:6, 5:7,9 
relocation 3:45 

global offset table procedure entry 5:10 
_GLOBAL_OFFSET_TABLE_ (see global 
offset table) 

I 

IEEE floating-point 3:17, 37-38 
illegal level change exception 3: 38 
illegal opcode exception 3: 38 
imprecise exceptions 3: 33-34 
indirection sequence 3: 51 
info protocols, tdesc 3: 59 
initialization, process 3: 38 
installation, software 2:1 
instructions, emulation 3:1 
int 3:2 
integer 

argument transmission 3:25 
result transmission 3: 27 
INTEGER data type 3:10, 27 
integer overflow exception 3: 38 
integer zero-divide exception 3:38 
interoperability, language 3:14,16, 26, 
28 

invalid descriptor exception 3:38 


J 

jmp instruction 3: 48 

L 

language interoperability 3:14,16, 26, 28 

lazy binding 5:10 

Id instruction 3: 48 

Ida instruction, restrictions 3: 1 

LD_BIND_NOW 5:10 

ld(SD_CMD) (see link editor) 

length 

argument 3:24 
parameter 3:24 
Level 01 items, COBOL 3: 11 
Level 1 1:2 

Level 2 1: 2, 3: 3 

Level 77 items, COBOL 3:11 
libsys 6:1 
link editor 5: 9 
link editor registers 3:19 
linkage, function (see calling sequence) 
Little-Endian byte order 6: 2 
local variable space 3: 22 
LOGICAL data type 3: 9-10, 27 
long 3:2 
long double 3: 2 
long double versus double 3: 3 
longjmp(BA_LIB) (see 
setjmp(BA_LiB)) 

M 

M88000 3:1,32, 43, 49, 54, 57-58, 5: 2-3 
machine exception 3:33 

main 

arguments 3:39 
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Index 


declaration 3:38 
mallOC(BA_OS) 3:31 
MC88100 3: 1, 18, 33, 54 

media, distribution 2:1 

memctlO 6: i 

memory allocation, stack 3: 54 
memory management 3:29 
memory return value register 3:19 
misaligned access 3: 40 
misaligned storage allocation 3:9 
mmap(KE_OS) 3:31 
modes, processor (see processor execu¬ 
tion mode) 

mprotect(KE_OS) 3: 36, 5: 2 , 16 

N 

no-op instruction 3: 58 
no-op instructions 3: 58 
null pointer 3: 2-3, 30, 39 
dereferencing 3:30 
numeric data class, COBOL 3:11 

O 

object file 4:1 
ELF header 4:1 
executable 3:45 
executable file 3: 45 
section 4:2 
see also archive file 4:1 
see also dynamic linking 5: 7 
see also executable file 4:1 
see also relocatable file 4:1 
see also shared object file 4:1 
segment 5:3 
shared object file 3: 45 


special sections 4: 2 
OCCURS clause 3:11 
OCS differences 6:13, 16, 24, 48, 50 
offset table, global (see global offset 
table) 

opcodes, use of unimplemented 3: 37 
optimization 3:57 
optionl scalar types 3:10 
or instruction 3: 48 

P 

PACKED-DECIMAL data type, COBOL 
3: 11 

padding, structure and union 3: 3 
page size 3: 29, 43, 5: 3 
paging 3: 29, 5: 3 
performance 5:3 
paging and exceptions 3: 37 
parameter 
alignment 3:24 
length 3:24 
passing 3:24 
parameter registers 3:19 
parameters 

function (see arguments) 
system configuration (see tunable 
parameters) 
passing 

arguments 3:24 
parameters 3:24 
results 3:26 
performance 3:1,9 
paging 5:3 

permissions, segment 5: 2 
physical addressing 3: 29 
PICTURE character strings, COBOL 
3:12 


Index 
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Index 


pipelined instructions 3: 33 
PLT region 5:8,16 
pointer 3:3 

argument transmission 3: 25 
null 3: 2-3, 30, 39 
result transmission 3: 27 
portability 
C program 3: 54 
instructions 3:1 

position-independent code 3: 44, 47, 5: 6 
see also absolute code 3: 44 
see also global offset table 3: 44 
see also procedure linkage table 3: 44 
precise exceptions 3:33-34 
privileged opcode exception 3: 38 
privileged register exception 3: 38 
procedure 
called 3:22 
entry 3:22 
return 3:22 

procedure linkage table 3: 45, 5: 7, 15 
relocation 3:45 
process 
dead 3:56 
entry point 3: 39 
initialization 3:38 
segment 3:29 
size 3:29 
stack 3:41 

virtual addressing 3: 29 
processor architecture 3:1 
processor execution mode 3: 32 
Processor Status Register (PSR) 3:1, 6:1 
processor-specific information 3:1, 18, 
29,44, 5:3,9,15, 6:1 
program counter, relative addressing (see 
XIP-relative) 
program loading 5: 3 


PSR 3:1 

purpose of ABI 1:1 

Q 

QIC cartridge 2:1 

R 

REAL data type 3:10, 27 
register 

memory return value 3:19 
stack pointer 3: 20 
registers 

calling sequence 3:19 
description 3:18-19 
floating-point 3:40 
general purpose 3:18 
initial values 3: 39, 41 
language-specific 3: 19 
parameter 3:19 
preserved 3:19 
reserved 3:40 
reserved for link editor 3:19 
saving 3:20 
scratch 3:19-20 
signals 3:20 
temporary 3:19 
relocation 

global offset table 3: 45 
procedure linkage table 3:45 
reserved data type exception 3: 38 
reserved opcode exception 3: 38 
resources, shared 3:29 
result, size 3: 26 
result transmission 3:26 
COBOL 3:28 
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Index 


floating-point 3:27 
FORTRAN 3:27 
integer 3:27 
pointer 3:27 
structure 3:27 
union 3:27 
results, passing 3: 26 
return 

pointer 3:19 
procedure 3:22 
return pointer 3:19 
return value register, memory 3:19 

S 

sbrk() 6:1 
scalar types 3: 2, 9 
optional 3:10 
scratch registers 3:19 
secondary storage 3: 29 
section, object file 5: 3 
segment 
dynamic 3:30 
permissions 5:4 
process 3: 29-30, 5: 3, 10 
segment permissions 3: 31, 5:2 
segments 
executable 5:2 
unshared 3:45 
writable 5:2 
Setjmp(BA_LIB) 3:56 
setpsr() 3:37,6:1 
Setrlimit(BA_OS) 3: 31,36 
shadow registers 3:40 
shared object file 3:45 
segments 3: 30, 5: 6 
short 3:2 

sigaction(BA_os) 3:33 


SIGBUS 5:2 
siginfo structure 3: 33 
SIGN clause, COBOL 3: 11 
sign extension, bit-field 3: 6 
sign representation, COBOL 3: 1 2 
signal(BA_os) 3 :20 
signals 3: 20, 56 
signed 3: 2 ,6 

signed characters, sign-extension 3: 25, 
27 

signed integers, sign-extension 3: 25, 27 
sign-extension 
signed characters 3: 25, 27 
signed integers 3: 25, 27 
single-precision 3: 2 
sizeof 3:2 
structure 3:3 
software installation 2:1 
space, variable, local 3: 22 
St instruction 3: 48 
stack 

address 3:41 
dynamic allocation 3: 54 
growth 3:20 
process 3:29-30 
system management 3: 31 
stack allocation, dynamic 3: 54 
stack frame 3:18, 21 
alignment 3:22 
form of 3: 57 
organization 3:20-21 
size 3:22 
stack pointer 3: 49 
stack pointer register 3: 20 
stack traceback 3: 62 
<stdarg.h> 3:54 
structure 3:3 

argument transmission 3: 25 


Index 
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padding 3:3 
result transmission 3: 27 
SLlbu instruction 3: 48 
symbol table 4: 3 
SySCOnf(BA_OS) 3: 29, 43 
system calls 6:1 
see also libsys 6:1 
system load 3: 29 

T 

tape 

QIC cartridge 2:1 
reel-to-reel 2:1 
tdesc info protocols 3: 59 
tdesc information 3: 57 
.tdesc section 3: 58 
temporary registers 3: 19 
termination, process 3: 56 
text 

process 3:29 
sharing 3:45 
text chunk 3:57 

text description (tdesc) information 3: 57 
text section 3: 57 
trace trap exception 3:38 
transmission 
argument 3: 24 
parameter 3: 24 
result 3: 26 
traps (see exceptions) 
traps, access exception 3:30 
tunable parameters 
process size 3: 29 
stack size 3: 31 


U 

ucontextj structure 3:33 
undefined behavior 3: 1, 25-27, 40-43, 59, 
5:4, 6: 1 

see also ABI conformance 3:1 
see also unspecified property 3:1, 
25-27, 40, 42-43, 59, 6: 1 
uninitialized data 5: 4 
union 3:3 

argument transmission 3: 25 
result transmission 3: 27 
unshared segments 3: 45 
unsigned 3: 2 ,6 

unsigned characters, zero-extension 
3: 25, 27-28 

unsigned integers, zero-extension 3: 25, 
27-28 

unspecified property 3:1,32, 5: 3, 5 
see also ABI conformance 3:1 
see also undefined behavior 3:1 
USAGE clause, COBOL 3:11 
user mode (see processor execution 
mode) 

User’s Manual 1:2 

V 

<varargs.h> 3:54 
variable argument list 3: 54 
variable space, local 3: 22 
virtual addressing 3: 29, 45 
bounds 3:30 
invalid 3:30 
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XIP-relative branch 3:45 
xrnem instruction, restrictions 3:1 


Z 


zero 

null pointer 3: 3, 30 
uninitialized data 5: 4 
virtual address 3: 30 
zero fill 3: 6 
zero-extension 

unsigned characters 3: 25, 27-28 
unsigned integers 3: 25, 27 
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